From dmuysers at hotmail.com  Sat May 25 16:49:52 2019
From: dmuysers at hotmail.com (dirk muysers)
Date: Sat, 25 May 2019 14:49:52 +0000
Subject: [M3devel] Impossible to compile to recent Windows versions
Message-ID: <LNXP123MB2089D144D3E8F89E4A1A14E2DD030@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>

My configuration:
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=AMD64 Family 21 Model 16 Stepping 1, AuthenticAMD
PROCESSOR_LEVEL=21
PROCESSOR_REVISION=1001
running Windows 7 Pro

I am using M3 release  "cm3-min-x86-d5.10.0-VC2015-20160102"

After struggling a lot I removed Visual Studio 10 (which I never use as such) and installed Microsoft Build Tools 2019
I then edited "NT.common" in bin/config:
-----
    Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools"
    VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702"
    DevEnvDir = Msdev & "\\Common7\\\IDE"
    end end end end
    if VCInstallDir
        VCBin = VCInstallDir & "\\bin\\Hostx64\\x86"
        VCLib = VCInstallDir & "\\lib"
        VCInc = VCInstallDir & "\\include"
    end
-----
and I still get:

Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.
-out:Maketables.exe
-subsystem:console
-entry:mainCRTStartup
-nodefaultlib
-debug
-incremental:no
-opt:ref
-delayload:ws2_32.dll
-delayload:advapi32.dll
-delayload:gdi32.dll
-delayload:netapi32.dll
-delayload:user32.dll
-delayload:comctl32.dll
-delayload:rpcrt4.dll
-delayload:iphlpapid.dll
delayimp.lib
_m3main.obj
Main.mo
Common.io
Common.mo
Loader.io
Loader.mo
Editor.io
Editor.mo
Printer.io
Printer.mo
C:\Users\Public\programs\cm3\pkg\libm3\NT386\m3.lib.sa
C:\Users\Public\programs\cm3\pkg\m3core\NT386\m3core.lib.sa
iphlpapi.lib
rpcrt4.lib
winspool.lib
comctl32.lib
ws2_32.lib
comdlg32.lib
netapi32.lib
gdi32.lib
user32.lib
advapi32.lib
kernel32.lib
msvcrt.lib
Main.mo : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'

After trying everything, worming my way through the configuration labyrinth, I am at the end of my wits.
If anybody has an idea...
Otherwise I can't use M3 anymore.
Am I the only one using Windows?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190525/d6b67cb9/attachment.html>

From RColeburn at comcast.net  Sat May 25 23:42:57 2019
From: RColeburn at comcast.net (Randy Coleburn)
Date: Sat, 25 May 2019 17:42:57 -0400
Subject: [M3devel] Impossible to compile to recent Windows versions
In-Reply-To: <LNXP123MB2089D144D3E8F89E4A1A14E2DD030@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
References: <LNXP123MB2089D144D3E8F89E4A1A14E2DD030@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <035701d51342$d1ed5960$75c80c20$@comcast.net>

I too can?t make Windows work anymore.

I can get some stuff to compile, but not everything.

--Randy Coleburn

 

From: M3devel <m3devel-bounces at elegosoft.com> On Behalf Of dirk muysers
Sent: Saturday, May 25, 2019 10:50 AM
To: m3devel at elegosoft.com
Subject: [M3devel] Impossible to compile to recent Windows versions

 

My configuration: 

PROCESSOR_ARCHITECTURE=AMD64

PROCESSOR_IDENTIFIER=AMD64 Family 21 Model 16 Stepping 1, AuthenticAMD

PROCESSOR_LEVEL=21

PROCESSOR_REVISION=1001

running Windows 7 Pro

 

I am using M3 release  "cm3-min-x86-d5.10.0-VC2015-20160102"

 

After struggling a lot I removed Visual Studio 10 (which I never use as such) and installed Microsoft Build Tools 2019

I then edited "NT.common" in bin/config:

-----

    Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools <file://Program%20Files%20(x86)/Microsoft%20Visual%20Studio/2019/BuildTools> "

    VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702 <file://VC/Tools/MSVC/14.21.27702> "

    DevEnvDir = Msdev & "\\Common7\\\IDE <file://Common7/IDE> "

    end end end end

    if VCInstallDir

        VCBin = VCInstallDir & "\\bin\\Hostx64\\x86 <file://bin/Hostx64/x86> "

        VCLib = VCInstallDir & "\\lib <file://lib> "

        VCInc = VCInstallDir & "\\include <file://include> "

    end

-----

and I still get:

 

Microsoft (R) Incremental Linker Version 10.00.30319.01

Copyright (C) Microsoft Corporation.  All rights reserved.

-out:Maketables.exe 

-subsystem:console 

-entry:mainCRTStartup 

-nodefaultlib 

-debug 

-incremental:no 

-opt:ref 

-delayload:ws2_32.dll 

-delayload:advapi32.dll 

-delayload:gdi32.dll 

-delayload:netapi32.dll 

-delayload:user32.dll 

-delayload:comctl32.dll 

-delayload:rpcrt4.dll 

-delayload:iphlpapid.dll 

delayimp.lib 

_m3main.obj 

Main.mo 

Common.io 

Common.mo 

Loader.io 

Loader.mo 

Editor.io 

Editor.mo 

Printer.io 

Printer.mo 

C:\Users\Public\programs\cm3\pkg\libm3\NT386\m3.lib.sa 

C:\Users\Public\programs\cm3\pkg\m3core\NT386\m3core.lib.sa 

iphlpapi.lib 

rpcrt4.lib 

winspool.lib 

comctl32.lib 

ws2_32.lib 

comdlg32.lib 

netapi32.lib 

gdi32.lib 

user32.lib 

advapi32.lib 

kernel32.lib 

msvcrt.lib 

Main.mo : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'

 

After trying everything, worming my way through the configuration labyrinth, I am at the end of my wits.

If anybody has an idea...

Otherwise I can't use M3 anymore.

Am I the only one using Windows?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190525/6e9c4868/attachment-0001.html>

From peter.mckinna at gmail.com  Sun May 26 09:20:48 2019
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sun, 26 May 2019 17:20:48 +1000
Subject: [M3devel] Impossible to compile to recent Windows versions
In-Reply-To: <035701d51342$d1ed5960$75c80c20$@comcast.net>
References: <LNXP123MB2089D144D3E8F89E4A1A14E2DD030@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <035701d51342$d1ed5960$75c80c20$@comcast.net>
Message-ID: <CAEy6uxrA3=xA1nBZD-yTJuJiWPY6d2o2vqh3fS_9EXnQk-fkbQ@mail.gmail.com>

Assuming you have the 32 bit environment setup via vcvars32.bat or the
newer vcvarsall.bat.

That error suggests you're trying to build a 32 bit program with a 64 bit
linker and libraries.

I can still compile m3 programs except I cant link in dll's - maybe Jay
could suggest a fix there.

Regards Peter


On Sun, May 26, 2019 at 7:43 AM Randy Coleburn <RColeburn at comcast.net>
wrote:

> I too can?t make Windows work anymore.
>
> I can get some stuff to compile, but not everything.
>
> --Randy Coleburn
>
>
>
> *From:* M3devel <m3devel-bounces at elegosoft.com> *On Behalf Of *dirk
> muysers
> *Sent:* Saturday, May 25, 2019 10:50 AM
> *To:* m3devel at elegosoft.com
> *Subject:* [M3devel] Impossible to compile to recent Windows versions
>
>
>
> My configuration:
>
> PROCESSOR_ARCHITECTURE=AMD64
>
> PROCESSOR_IDENTIFIER=AMD64 Family 21 Model 16 Stepping 1, AuthenticAMD
>
> PROCESSOR_LEVEL=21
>
> PROCESSOR_REVISION=1001
>
> running Windows 7 Pro
>
>
>
> I am using M3 release  "cm3-min-x86-d5.10.0-VC2015-20160102"
>
>
>
> After struggling a lot I removed Visual Studio 10 (which I never use as
> such) and installed Microsoft Build Tools 2019
>
> I then edited "NT.common" in bin/config:
>
> -----
>
>     Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual
> Studio\\2019\\BuildTools"
>
>     VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702"
>
>     DevEnvDir = Msdev & "\\Common7\\\IDE"
>
>     end end end end
>
>     if VCInstallDir
>
>         VCBin = VCInstallDir & "\\bin\\Hostx64\\x86"
>
>         VCLib = VCInstallDir & "\\lib"
>
>         VCInc = VCInstallDir & "\\include"
>
>     end
>
> -----
>
> and I still get:
>
>
>
> Microsoft (R) Incremental Linker Version 10.00.30319.01
>
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> -out:Maketables.exe
>
> -subsystem:console
>
> -entry:mainCRTStartup
>
> -nodefaultlib
>
> -debug
>
> -incremental:no
>
> -opt:ref
>
> -delayload:ws2_32.dll
>
> -delayload:advapi32.dll
>
> -delayload:gdi32.dll
>
> -delayload:netapi32.dll
>
> -delayload:user32.dll
>
> -delayload:comctl32.dll
>
> -delayload:rpcrt4.dll
>
> -delayload:iphlpapid.dll
>
> delayimp.lib
>
> _m3main.obj
>
> Main.mo
>
> Common.io
>
> Common.mo
>
> Loader.io
>
> Loader.mo
>
> Editor.io
>
> Editor.mo
>
> Printer.io
>
> Printer.mo
>
> C:\Users\Public\programs\cm3\pkg\libm3\NT386\m3.lib.sa
>
> C:\Users\Public\programs\cm3\pkg\m3core\NT386\m3core.lib.sa
>
> iphlpapi.lib
>
> rpcrt4.lib
>
> winspool.lib
>
> comctl32.lib
>
> ws2_32.lib
>
> comdlg32.lib
>
> netapi32.lib
>
> gdi32.lib
>
> user32.lib
>
> advapi32.lib
>
> kernel32.lib
>
> msvcrt.lib
>
> Main.mo : fatal error LNK1112: module machine type 'X86' conflicts with
> target machine type 'x64'
>
>
>
> After trying everything, worming my way through the configuration
> labyrinth, I am at the end of my wits.
>
> If anybody has an idea...
>
> Otherwise I can't use M3 anymore.
>
> Am I the only one using Windows?
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190526/bc9a2140/attachment.html>

From jayk123 at hotmail.com  Sun May 26 13:07:11 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sun, 26 May 2019 11:07:11 +0000
Subject: [M3devel] Impossible to compile to recent Windows versions
In-Reply-To: <CAEy6uxrA3=xA1nBZD-yTJuJiWPY6d2o2vqh3fS_9EXnQk-fkbQ@mail.gmail.com>
References: <LNXP123MB2089D144D3E8F89E4A1A14E2DD030@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <035701d51342$d1ed5960$75c80c20$@comcast.net>,
 <CAEy6uxrA3=xA1nBZD-yTJuJiWPY6d2o2vqh3fS_9EXnQk-fkbQ@mail.gmail.com>
Message-ID: <BN8PR03MB478629EB0B293AAF1FEA5443E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>

install pyhon (2.7)
 e.g. to c:\python2.7?
?
download and extract?
 http://www.opencm3.net/releng/cm3-bin-min-NT386-5.8.6-REL.tgz?
You get system.tgz?
 Extract that.?
?
Do not run the installer or update the .cfg.?
 I never liked the installer and I wrote .cfg files?
 that try to adapt to the environment and multiple releases of cm3 (try an older one? ?)

Put it in e.g.?
 c:\cm3\bin\cm3.exe?
?
git clone current cm3?
?
run developer command prompt?
 verify cl.exe runs and says ..x86?
?
put python in path:?
 path=C:\Python27;%path%?
?
go into git clone:?
 cd C:\s\cm3\scripts\python?
?
install latest config files:
 python install-config.py?
?
?
apply very small change for newer compiler:
 https://github.com/modula3/cm3/pull/48?
?
python upgrade.py?
?
or rather, look at upgrade-full.cmd:?
 python upgrade.py?
 python do-cm3-all.py realclean skipgcc?
 python do-cm3-all.py buildship?
?
At least upgrade.py worked for me.?
 I'm doing the rest.?
?
Now to fix some things. :)?


hm:

..\src\FastNumParse.m3", line 3: warning: not used (Fmt)
2 warnings encountered?
new source -> compiling printf.c?
new source -> compiling getloadavg_glue.c?
new source -> compiling diskAvail.c?
cl.exe -nologo -DWIN32 -Zl -Ic:/cm3/pkg/m3core/src/unix/Common -Ic:/cm3/pkg/m3core/src -Ic:/cm3/pkg/m3core/src/Csupport/Common -Ic:/cm3/pkg/m3core/src/Csupport/little-endian -Ic:/cm3/pkg/m3core/src/Csupport/libgcc -Ic:/cm3/pkg/m3core/src/runtime/common -Ic:/cm3/pkg/m3core/src/runtime/WIN32 -Ic:/cm3/pkg/m3core/src/runtime/ex_frame -Ic:/cm3/pkg/m3core/src/thread/Common -Ic:/cm3/pkg/m3core/src/thread/WIN32 -Ic:/cm3/pkg/m3core/src/win32 -Ic:/cm3/pkg/m3core/src/C/Common -Ic:/cm3/pkg/m3core/src/time/WIN32 -Ic:/cm3/pkg/libm3/src/uid/WIN32 -Ic:/cm3/pkg/patternmatching/src/libglob -I../src -Z7 -MD -Ox -Oi -c ..\\src\\diskAvail.c -FodiskAvail.obj?
diskAvail.c?
..\\src\\diskAvail.c(5): fatal error C1083: Cannot open include file: 'sys/param.h': No such file or directory?
  compile_c => 2?
C compiler failed compiling: ..\src\diskAvail.c?
new source -> compiling CTZ.c?
new source -> compiling UtimeOpsC.c?
cl.exe -nologo -DWIN32 -Zl -Ic:/cm3/pkg/m3core/src/unix/Common -Ic:/cm3/pkg/m3core/src -Ic:/cm3/pkg/m3core/src/Csupport/Common -Ic:/cm3/pkg/m3core/src/Csupport/little-endian -Ic:/cm3/pkg/m3core/src/Csupport/libgcc -Ic:/cm3/pkg/m3core/src/runtime/common -Ic:/cm3/pkg/m3core/src/runtime/WIN32 -Ic:/cm3/pkg/m3core/src/runtime/ex_frame -Ic:/cm3/pkg/m3core/src/thread/Common -Ic:/cm3/pkg/m3core/src/thread/WIN32 -Ic:/cm3/pkg/m3core/src/win32 -Ic:/cm3/pkg/m3core/src/C/Common -Ic:/cm3/pkg/m3core/src/time/WIN32 -Ic:/cm3/pkg/libm3/src/uid/WIN32 -Ic:/cm3/pkg/patternmatching/src/libglob -I../src -Z7 -MD -Ox -Oi -c ..\\src\\UtimeOpsC.c -FoUtimeOpsC.obj?
UtimeOpsC.c?
..\\src\\UtimeOpsC.c(62): error C2039: 'tm_gmtoff': is not a member of 'tm'?
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_wtime.h(22): note: see declaration of 'tm'?
..\\src\\UtimeOpsC.c(62): warning C4033: 'UtimeOpsC__Get_gmtoff' must return a value?
..\\src\\UtimeOpsC.c(75): error C2039: 'tm_zone': is not a member of 'tm'?
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_wtime.h(22): note: see declaration of 'tm'?
..\\src\\UtimeOpsC.c(75): warning C4033: 'UtimeOpsC__Get_zone' must return a value?
..\\src\\UtimeOpsC.c(123): error C2039: 'tm_gmtoff': is not a member of 'tm'?
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_wtime.h(22): note: see declaration of 'tm'?
..\\src\\UtimeOpsC.c(134): warning C4047: 'initializing': 'tm *' differs in levels of indirection from 'int'?
..\\src\\UtimeOpsC.c(158): warning C4047: 'return': 'char *' differs in levels of indirection from 'int'?
  compile_c => 2?
C compiler failed compiling: ..\src\UtimeOpsC.c?
new exporters -> recompiling Debug.i3?
new exporters -> recompiling TextUtils.i3?
new exporters -> recompiling RTBrand.i3?
new exporters -> recompiling RefRecord.i3?
new exporters -> recompiling SchedulerIndirection.i3?
new exporters -> recompiling FileSharing.i3?
new exporters -> recompiling TZ.i3?
new exporters -> recompiling HMTime.i3?
compilation failed => not building library "cit_util.lib"?
Fatal Error: package build failed?
 *** execution of [<function _BuildGlobalFunction at 0x00000000039630B8>, <function _ShipFunction at 0x0000000003963128>] failed ***?
?
 - Jay


________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Peter McKinna <peter.mckinna at gmail.com>
Sent: Sunday, May 26, 2019 7:20 AM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] Impossible to compile to recent Windows versions

Assuming you have the 32 bit environment setup via vcvars32.bat or the newer vcvarsall.bat.

That error suggests you're trying to build a 32 bit program with a 64 bit linker and libraries.

I can still compile m3 programs except I cant link in dll's - maybe Jay could suggest a fix there.

Regards Peter


On Sun, May 26, 2019 at 7:43 AM Randy Coleburn <RColeburn at comcast.net<mailto:RColeburn at comcast.net>> wrote:

I too can?t make Windows work anymore.

I can get some stuff to compile, but not everything.

--Randy Coleburn



From: M3devel <m3devel-bounces at elegosoft.com<mailto:m3devel-bounces at elegosoft.com>> On Behalf Of dirk muysers
Sent: Saturday, May 25, 2019 10:50 AM
To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Subject: [M3devel] Impossible to compile to recent Windows versions



My configuration:

PROCESSOR_ARCHITECTURE=AMD64

PROCESSOR_IDENTIFIER=AMD64 Family 21 Model 16 Stepping 1, AuthenticAMD

PROCESSOR_LEVEL=21

PROCESSOR_REVISION=1001

running Windows 7 Pro



I am using M3 release  "cm3-min-x86-d5.10.0-VC2015-20160102"



After struggling a lot I removed Visual Studio 10 (which I never use as such) and installed Microsoft Build Tools 2019

I then edited "NT.common" in bin/config:

-----

    Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools"

    VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702"

    DevEnvDir = Msdev & "\\Common7\\\IDE"

    end end end end

    if VCInstallDir

        VCBin = VCInstallDir & "\\bin\\Hostx64\\x86"

        VCLib = VCInstallDir & "\\lib"

        VCInc = VCInstallDir & "\\include"

    end

-----

and I still get:



Microsoft (R) Incremental Linker Version 10.00.30319.01

Copyright (C) Microsoft Corporation.  All rights reserved.

-out:Maketables.exe

-subsystem:console

-entry:mainCRTStartup

-nodefaultlib

-debug

-incremental:no

-opt:ref

-delayload:ws2_32.dll

-delayload:advapi32.dll

-delayload:gdi32.dll

-delayload:netapi32.dll

-delayload:user32.dll

-delayload:comctl32.dll

-delayload:rpcrt4.dll

-delayload:iphlpapid.dll

delayimp.lib

_m3main.obj

Main.mo

Common.io

Common.mo

Loader.io

Loader.mo

Editor.io

Editor.mo

Printer.io

Printer.mo

C:\Users\Public\programs\cm3\pkg\libm3\NT386\m3.lib.sa<http://m3.lib.sa>

C:\Users\Public\programs\cm3\pkg\m3core\NT386\m3core.lib.sa<http://m3core.lib.sa>

iphlpapi.lib

rpcrt4.lib

winspool.lib

comctl32.lib

ws2_32.lib

comdlg32.lib

netapi32.lib

gdi32.lib

user32.lib

advapi32.lib

kernel32.lib

msvcrt.lib

Main.mo : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'



After trying everything, worming my way through the configuration labyrinth, I am at the end of my wits.

If anybody has an idea...

Otherwise I can't use M3 anymore.

Am I the only one using Windows?

_______________________________________________
M3devel mailing list
M3devel at elegosoft.com<mailto:M3devel at elegosoft.com>
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190526/d7d7f3a8/attachment-0001.html>

From jayk123 at hotmail.com  Sun May 26 14:27:52 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sun, 26 May 2019 12:27:52 +0000
Subject: [M3devel] Impossible to compile to recent Windows versions
In-Reply-To: <BN8PR03MB478629EB0B293AAF1FEA5443E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <LNXP123MB2089D144D3E8F89E4A1A14E2DD030@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <035701d51342$d1ed5960$75c80c20$@comcast.net>,
 <CAEy6uxrA3=xA1nBZD-yTJuJiWPY6d2o2vqh3fS_9EXnQk-fkbQ@mail.gmail.com>,
 <BN8PR03MB478629EB0B293AAF1FEA5443E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <BN8PR03MB4786F210DA7A769E1AC29667E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>

https://github.com/modula3/cm3/pull/50
https://github.com/modula3/cm3/pull/48

hopefully more soon..

 - Jay

________________________________
From: Jay K
Sent: Sunday, May 26, 2019 11:07 AM
To: Peter McKinna; Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] Impossible to compile to recent Windows versions

install pyhon (2.7)
 e.g. to c:\python2.7?
?
download and extract?
 http://www.opencm3.net/releng/cm3-bin-min-NT386-5.8.6-REL.tgz?
You get system.tgz?
 Extract that.?
?
Do not run the installer or update the .cfg.?
 I never liked the installer and I wrote .cfg files?
 that try to adapt to the environment and multiple releases of cm3 (try an older one? ?)

Put it in e.g.?
 c:\cm3\bin\cm3.exe?
?
git clone current cm3?
?
run developer command prompt?
 verify cl.exe runs and says ..x86?
?
put python in path:?
 path=C:\Python27;%path%?
?
go into git clone:?
 cd C:\s\cm3\scripts\python?
?
install latest config files:
 python install-config.py?
?
?
apply very small change for newer compiler:
 https://github.com/modula3/cm3/pull/48?
?
python upgrade.py?
?
or rather, look at upgrade-full.cmd:?
 python upgrade.py?
 python do-cm3-all.py realclean skipgcc?
 python do-cm3-all.py buildship?
?
At least upgrade.py worked for me.?
 I'm doing the rest.?
?
Now to fix some things. :)?


hm:

..\src\FastNumParse.m3", line 3: warning: not used (Fmt)
2 warnings encountered?
new source -> compiling printf.c?
new source -> compiling getloadavg_glue.c?
new source -> compiling diskAvail.c?
cl.exe -nologo -DWIN32 -Zl -Ic:/cm3/pkg/m3core/src/unix/Common -Ic:/cm3/pkg/m3core/src -Ic:/cm3/pkg/m3core/src/Csupport/Common -Ic:/cm3/pkg/m3core/src/Csupport/little-endian -Ic:/cm3/pkg/m3core/src/Csupport/libgcc -Ic:/cm3/pkg/m3core/src/runtime/common -Ic:/cm3/pkg/m3core/src/runtime/WIN32 -Ic:/cm3/pkg/m3core/src/runtime/ex_frame -Ic:/cm3/pkg/m3core/src/thread/Common -Ic:/cm3/pkg/m3core/src/thread/WIN32 -Ic:/cm3/pkg/m3core/src/win32 -Ic:/cm3/pkg/m3core/src/C/Common -Ic:/cm3/pkg/m3core/src/time/WIN32 -Ic:/cm3/pkg/libm3/src/uid/WIN32 -Ic:/cm3/pkg/patternmatching/src/libglob -I../src -Z7 -MD -Ox -Oi -c ..\\src\\diskAvail.c -FodiskAvail.obj?
diskAvail.c?
..\\src\\diskAvail.c(5): fatal error C1083: Cannot open include file: 'sys/param.h': No such file or directory?
  compile_c => 2?
C compiler failed compiling: ..\src\diskAvail.c?
new source -> compiling CTZ.c?
new source -> compiling UtimeOpsC.c?
cl.exe -nologo -DWIN32 -Zl -Ic:/cm3/pkg/m3core/src/unix/Common -Ic:/cm3/pkg/m3core/src -Ic:/cm3/pkg/m3core/src/Csupport/Common -Ic:/cm3/pkg/m3core/src/Csupport/little-endian -Ic:/cm3/pkg/m3core/src/Csupport/libgcc -Ic:/cm3/pkg/m3core/src/runtime/common -Ic:/cm3/pkg/m3core/src/runtime/WIN32 -Ic:/cm3/pkg/m3core/src/runtime/ex_frame -Ic:/cm3/pkg/m3core/src/thread/Common -Ic:/cm3/pkg/m3core/src/thread/WIN32 -Ic:/cm3/pkg/m3core/src/win32 -Ic:/cm3/pkg/m3core/src/C/Common -Ic:/cm3/pkg/m3core/src/time/WIN32 -Ic:/cm3/pkg/libm3/src/uid/WIN32 -Ic:/cm3/pkg/patternmatching/src/libglob -I../src -Z7 -MD -Ox -Oi -c ..\\src\\UtimeOpsC.c -FoUtimeOpsC.obj?
UtimeOpsC.c?
..\\src\\UtimeOpsC.c(62): error C2039: 'tm_gmtoff': is not a member of 'tm'?
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_wtime.h(22): note: see declaration of 'tm'?
..\\src\\UtimeOpsC.c(62): warning C4033: 'UtimeOpsC__Get_gmtoff' must return a value?
..\\src\\UtimeOpsC.c(75): error C2039: 'tm_zone': is not a member of 'tm'?
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_wtime.h(22): note: see declaration of 'tm'?
..\\src\\UtimeOpsC.c(75): warning C4033: 'UtimeOpsC__Get_zone' must return a value?
..\\src\\UtimeOpsC.c(123): error C2039: 'tm_gmtoff': is not a member of 'tm'?
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_wtime.h(22): note: see declaration of 'tm'?
..\\src\\UtimeOpsC.c(134): warning C4047: 'initializing': 'tm *' differs in levels of indirection from 'int'?
..\\src\\UtimeOpsC.c(158): warning C4047: 'return': 'char *' differs in levels of indirection from 'int'?
  compile_c => 2?
C compiler failed compiling: ..\src\UtimeOpsC.c?
new exporters -> recompiling Debug.i3?
new exporters -> recompiling TextUtils.i3?
new exporters -> recompiling RTBrand.i3?
new exporters -> recompiling RefRecord.i3?
new exporters -> recompiling SchedulerIndirection.i3?
new exporters -> recompiling FileSharing.i3?
new exporters -> recompiling TZ.i3?
new exporters -> recompiling HMTime.i3?
compilation failed => not building library "cit_util.lib"?
Fatal Error: package build failed?
 *** execution of [<function _BuildGlobalFunction at 0x00000000039630B8>, <function _ShipFunction at 0x0000000003963128>] failed ***?
?
 - Jay


________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Peter McKinna <peter.mckinna at gmail.com>
Sent: Sunday, May 26, 2019 7:20 AM
To: Randy Coleburn
Cc: m3devel
Subject: Re: [M3devel] Impossible to compile to recent Windows versions

Assuming you have the 32 bit environment setup via vcvars32.bat or the newer vcvarsall.bat.

That error suggests you're trying to build a 32 bit program with a 64 bit linker and libraries.

I can still compile m3 programs except I cant link in dll's - maybe Jay could suggest a fix there.

Regards Peter


On Sun, May 26, 2019 at 7:43 AM Randy Coleburn <RColeburn at comcast.net<mailto:RColeburn at comcast.net>> wrote:

I too can?t make Windows work anymore.

I can get some stuff to compile, but not everything.

--Randy Coleburn



From: M3devel <m3devel-bounces at elegosoft.com<mailto:m3devel-bounces at elegosoft.com>> On Behalf Of dirk muysers
Sent: Saturday, May 25, 2019 10:50 AM
To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Subject: [M3devel] Impossible to compile to recent Windows versions



My configuration:

PROCESSOR_ARCHITECTURE=AMD64

PROCESSOR_IDENTIFIER=AMD64 Family 21 Model 16 Stepping 1, AuthenticAMD

PROCESSOR_LEVEL=21

PROCESSOR_REVISION=1001

running Windows 7 Pro



I am using M3 release  "cm3-min-x86-d5.10.0-VC2015-20160102"



After struggling a lot I removed Visual Studio 10 (which I never use as such) and installed Microsoft Build Tools 2019

I then edited "NT.common" in bin/config:

-----

    Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools"

    VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702"

    DevEnvDir = Msdev & "\\Common7\\\IDE"

    end end end end

    if VCInstallDir

        VCBin = VCInstallDir & "\\bin\\Hostx64\\x86"

        VCLib = VCInstallDir & "\\lib"

        VCInc = VCInstallDir & "\\include"

    end

-----

and I still get:



Microsoft (R) Incremental Linker Version 10.00.30319.01

Copyright (C) Microsoft Corporation.  All rights reserved.

-out:Maketables.exe

-subsystem:console

-entry:mainCRTStartup

-nodefaultlib

-debug

-incremental:no

-opt:ref

-delayload:ws2_32.dll

-delayload:advapi32.dll

-delayload:gdi32.dll

-delayload:netapi32.dll

-delayload:user32.dll

-delayload:comctl32.dll

-delayload:rpcrt4.dll

-delayload:iphlpapid.dll

delayimp.lib

_m3main.obj

Main.mo

Common.io

Common.mo

Loader.io

Loader.mo

Editor.io

Editor.mo

Printer.io

Printer.mo

C:\Users\Public\programs\cm3\pkg\libm3\NT386\m3.lib.sa<http://m3.lib.sa>

C:\Users\Public\programs\cm3\pkg\m3core\NT386\m3core.lib.sa<http://m3core.lib.sa>

iphlpapi.lib

rpcrt4.lib

winspool.lib

comctl32.lib

ws2_32.lib

comdlg32.lib

netapi32.lib

gdi32.lib

user32.lib

advapi32.lib

kernel32.lib

msvcrt.lib

Main.mo : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'



After trying everything, worming my way through the configuration labyrinth, I am at the end of my wits.

If anybody has an idea...

Otherwise I can't use M3 anymore.

Am I the only one using Windows?

_______________________________________________
M3devel mailing list
M3devel at elegosoft.com<mailto:M3devel at elegosoft.com>
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190526/2ac2b9b1/attachment-0001.html>

From dmuysers at hotmail.com  Sun May 26 14:45:58 2019
From: dmuysers at hotmail.com (dirk muysers)
Date: Sun, 26 May 2019 12:45:58 +0000
Subject: [M3devel] Windows with MS BuildTool
Message-ID: <LNXP123MB20894793E0749F5EBEE30B7CDD1C0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>

The problem is:
Since I never use Visual Studio per se, I unistalled the whole thing and
replaced it with the Visual Studio 2019 BuildTool, modifying "NT.common" as
follows:
--------------
%      Msdev = SystemDrive & "\\msdev\\80"
   Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools"
         VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702"
         DevEnvDir = Msdev & "\\Common7\\\IDE"
         end end end end

        if VCInstallDir
            VCBin = VCInstallDir & "\\bin\\Hostx64\\x86"
            VCLib = VCInstallDir & "\\lib"
            VCInc = VCInstallDir & "\\include"
        end
---------------------

The MS 2019 build tool, has four sets of executables. Under "bin" two directories Host64 and Host32,
and, for both of them, targets x64 and x86.
I thus compiled using Host64, target x86 and still get the bloody LNK1112 error!

And trying to follow what happens through the umpteen Russian Doll config files is near impossible for someone who did not participate in the setting-up of the whole thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190526/d37c4912/attachment.html>

From vvm at tut.by  Sun May 26 16:55:58 2019
From: vvm at tut.by (vvm at tut.by)
Date: Sun, 26 May 2019 17:55:58 +0300
Subject: [M3devel] Modula-3 for Windows x64
Message-ID: <12849991558882558@iva6-62cf6ab2a3cd.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190526/e09b8728/attachment.html>

From jayk123 at hotmail.com  Sun May 26 19:55:59 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sun, 26 May 2019 17:55:59 +0000
Subject: [M3devel] Windows with MS BuildTool
In-Reply-To: <LNXP123MB20894793E0749F5EBEE30B7CDD1C0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
References: <LNXP123MB20894793E0749F5EBEE30B7CDD1C0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <BN8PR03MB4786AA47EC2ED2F1ABFCED8BE61C0@BN8PR03MB4786.namprd03.prod.outlook.com>

Ideally if cl.exe and link.exe are already in PATH and LIB is already set, we don't have to run any of that.
I'll have to install 2019 and see.

 - Jay

________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of dirk muysers <dmuysers at hotmail.com>
Sent: Sunday, May 26, 2019 12:45 PM
To: m3devel at elegosoft.com
Subject: [M3devel] Windows with MS BuildTool

The problem is:
Since I never use Visual Studio per se, I unistalled the whole thing and
replaced it with the Visual Studio 2019 BuildTool, modifying "NT.common" as
follows:
--------------
%      Msdev = SystemDrive & "\\msdev\\80"
   Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools"
         VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702"
         DevEnvDir = Msdev & "\\Common7\\\IDE"
         end end end end

        if VCInstallDir
            VCBin = VCInstallDir & "\\bin\\Hostx64\\x86"
            VCLib = VCInstallDir & "\\lib"
            VCInc = VCInstallDir & "\\include"
        end
---------------------

The MS 2019 build tool, has four sets of executables. Under "bin" two directories Host64 and Host32,
and, for both of them, targets x64 and x86.
I thus compiled using Host64, target x86 and still get the bloody LNK1112 error!

And trying to follow what happens through the umpteen Russian Doll config files is near impossible for someone who did not participate in the setting-up of the whole thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190526/531ec917/attachment.html>

From jayk123 at hotmail.com  Sun May 26 20:11:54 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sun, 26 May 2019 18:11:54 +0000
Subject: [M3devel] integer types?
Message-ID: <BN8PR03MB4786E9D7EF43987D0B2C2454E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>

This may be repeat topic.
I think I had tried this before and ran into problems, but:?
?
INTERFACE BasicCtypes;?
?
  (* the four signed integer types *)?
  signed_char        = [-16_7f-1 .. 16_7f];?
  short_int          = [-16_7fff-1 .. 16_7fff];?
  int                = [-16_7fffffff-1 .. 16_7fffffff];?
  unsigned_char      = [16_0 .. 16_ff];?
  unsigned_short_int = [16_0 .. 16_ffff];?
?
?
seems like it should be:
?
  (* the four signed integer types *)?
  signed_char        = BITS 8 FOR [-16_7f-1 .. 16_7f];?
  short_int          = BITS 16 FOR [-16_7fff-1 .. 16_7fff];?
  int                = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];?
  unsigned_char      = BITS 8 [16_0 .. 16_ff];?
  unsigned_short_int = BITS 16 [16_0 .. 16_ffff];?
?
and then really, worse:?
?
  unsigned_int       = Word.T;?

looks wrong in multiple ways.
?
imagine passing this as VAR to C for example.

 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190526/e1449191/attachment-0001.html>

From jayk123 at hotmail.com  Sun May 26 20:57:11 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sun, 26 May 2019 18:57:11 +0000
Subject: [M3devel] Windows with MS BuildTool
In-Reply-To: <LNXP123MB20894793E0749F5EBEE30B7CDD1C0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
References: <LNXP123MB20894793E0749F5EBEE30B7CDD1C0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <BN8PR03MB478638A9D27056F776B1F6F8E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>

I just ran "developer command prompt for VS 2019" and gives me:


C:\>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for x86?
usage: cl [ option... ] filename... [ /link linkoption... ]?
?
C:\>where cl.exe?
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\Hostx86\x86\cl.exe?


I'll update pylib.py to mape 19.2 to 2019.

Perhaps we should just preprocess _MSC_VER and use that though.


C:\s>echo _MSC_VER >1.c?
?
C:\s>cl -EP 1.c?
Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for x86?
1.c?
?
1921?

This is on an amd64 system which is all anyone uses these days.

This version is used to stamp into distribution archive names, which is a rare use-case.
And we need to know if it is 2015 or newer, to guide linking, which we can either default or I can try to detect otherwise, or I can revisit, maybe we don't care.
We have our own build system and such, you know.
I'd kinda like to generate cmake or automake files instead.
That'd help the Unix distribution/setup story.
I know nobody likes automake and perhaps cmake, but nobody likes to maintain their own either, I think.

 - Jay

________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of dirk muysers <dmuysers at hotmail.com>
Sent: Sunday, May 26, 2019 12:45 PM
To: m3devel at elegosoft.com
Subject: [M3devel] Windows with MS BuildTool

The problem is:
Since I never use Visual Studio per se, I unistalled the whole thing and
replaced it with the Visual Studio 2019 BuildTool, modifying "NT.common" as
follows:
--------------
%      Msdev = SystemDrive & "\\msdev\\80"
   Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools"
         VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702"
         DevEnvDir = Msdev & "\\Common7\\\IDE"
         end end end end

        if VCInstallDir
            VCBin = VCInstallDir & "\\bin\\Hostx64\\x86"
            VCLib = VCInstallDir & "\\lib"
            VCInc = VCInstallDir & "\\include"
        end
---------------------

The MS 2019 build tool, has four sets of executables. Under "bin" two directories Host64 and Host32,
and, for both of them, targets x64 and x86.
I thus compiled using Host64, target x86 and still get the bloody LNK1112 error!

And trying to follow what happens through the umpteen Russian Doll config files is near impossible for someone who did not participate in the setting-up of the whole thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190526/423ec607/attachment.html>

From jayk123 at hotmail.com  Sun May 26 22:38:16 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sun, 26 May 2019 20:38:16 +0000
Subject: [M3devel] CI for modula-3
Message-ID: <BN8PR03MB47866DBC0BBB5342E0BBFD8EE61C0@BN8PR03MB4786.namprd03.prod.outlook.com>

Presumably we should have some CI?
Something free as in beer?
Travis?

 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190526/072a1a1a/attachment.html>

From jayk123 at hotmail.com  Sun May 26 23:13:35 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sun, 26 May 2019 21:13:35 +0000
Subject: [M3devel] -boot and C backend broken by LLVM?
Message-ID: <BN8PR03MB4786A48F68FE5D2B93F449C6E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>

I'm pretty sure the merging of the LLVM builder support circa 2015 broke C backend with -boot.
This is e.g. how you start with AMD64_NT. Well, other than an existing distribution.

The pattern of commenting out large functions, marking them "original" and making new ones nearby is kinda harmful.

I'll try to fix it.

I find the builder to be a bit of spaghetti code but maybe I just lack context.

 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190526/bbfa765d/attachment-0001.html>

From jayk123 at hotmail.com  Sun May 26 23:26:04 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sun, 26 May 2019 21:26:04 +0000
Subject: [M3devel] meaning of cm3 -boot?
Message-ID: <BN8PR03MB478647742288B0D6D5B308DDE61C0@BN8PR03MB4786.namprd03.prod.outlook.com>

I think the term "bootstrap" maybe is too vague.
?
There are various pipelines, like:?
?
 Gcc-based backend:?
 .m3 => .mc => .s/.o => link?
?
 Integrated backend:?
 .m3 => .o => link?
?
 C backend:?
 .m3 => .m3.c => s/.o  => link?
?
?
"boot" means, stop at some point, and run the rest later.?
?
Just because, cross tools might be less available than native tools,?
such as when crossing from Unix to Windows,?
or we might want to redistribute intermediate files in order?
to have an install w/o cm3, but w/ C compiler or assembler?
?
Maybe it'd be better to have flags like:?
 -stop-at-c (run C compiler and linker later) ?
 -stop-at-s (run assembly and linker linker) ?
 -stop-at-o (run link later) ?
?
Note that this is confusing too, because each pipeline?
outputs multiple possible formats, so has multiple possible?
stopping points.?
?
i.e. A backend might output assembly or .o?
?
In the "original" 3.6 era, -boot meant to stop at .s and c.?
?
Perhaps that is approximately ideal, i.e. to at least stop?
at text files, for which many tools exist, and not "binary" files,?
even if the .s/.c might be "derived", as the .s were back then.?

In the presence of decent cross assembly/Ccompiler/linker,
unless forming redistributable text files, this isn't needed.
?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190526/5b13a27c/attachment.html>

From jayk123 at hotmail.com  Sun May 26 23:43:16 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sun, 26 May 2019 21:43:16 +0000
Subject: [M3devel] -boot and C backend broken by LLVM?
In-Reply-To: <BN8PR03MB4786A48F68FE5D2B93F449C6E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB4786A48F68FE5D2B93F449C6E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <BN8PR03MB478639DB07EF9FEEAC183952E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>

I think in particular PushOneM3 got replaced. ?
I'll keep looking at it..

________________________________
From: Jay K
Sent: Sunday, May 26, 2019 9:13 PM
To: m3devel; rodney.m.bates at acm.org
Subject: -boot and C backend broken by LLVM?

I'm pretty sure the merging of the LLVM builder support circa 2015 broke C backend with -boot.
This is e.g. how you start with AMD64_NT. Well, other than an existing distribution.

The pattern of commenting out large functions, marking them "original" and making new ones nearby is kinda harmful.

I'll try to fix it.

I find the builder to be a bit of spaghetti code but maybe I just lack context.

 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190526/cd72a4ec/attachment.html>

From jayk123 at hotmail.com  Mon May 27 09:34:17 2019
From: jayk123 at hotmail.com (Jay K)
Date: Mon, 27 May 2019 07:34:17 +0000
Subject: [M3devel] -boot and C backend broken by LLVM?
In-Reply-To: <BN8PR03MB478639DB07EF9FEEAC183952E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB4786A48F68FE5D2B93F449C6E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>,
 <BN8PR03MB478639DB07EF9FEEAC183952E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <BN8PR03MB47862329A9135027C58623C2E61D0@BN8PR03MB4786.namprd03.prod.outlook.com>

Oh, sorry, maybe it works.
I can get all the .c files out and compile and link, and crash. Will investigate more..

  - Jay

________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Jay K <jayk123 at hotmail.com>
Sent: Sunday, May 26, 2019 9:43 PM
To: m3devel; rodney.m.bates at acm.org
Subject: Re: [M3devel] -boot and C backend broken by LLVM?

I think in particular PushOneM3 got replaced. ?
I'll keep looking at it..

________________________________
From: Jay K
Sent: Sunday, May 26, 2019 9:13 PM
To: m3devel; rodney.m.bates at acm.org
Subject: -boot and C backend broken by LLVM?

I'm pretty sure the merging of the LLVM builder support circa 2015 broke C backend with -boot.
This is e.g. how you start with AMD64_NT. Well, other than an existing distribution.

The pattern of commenting out large functions, marking them "original" and making new ones nearby is kinda harmful.

I'll try to fix it.

I find the builder to be a bit of spaghetti code but maybe I just lack context.

 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190527/a85526b9/attachment-0001.html>

From jayk123 at hotmail.com  Mon May 27 10:11:04 2019
From: jayk123 at hotmail.com (Jay K)
Date: Mon, 27 May 2019 08:11:04 +0000
Subject: [M3devel] reducing support for old..?
Message-ID: <BN8PR03MB4786C6B7440FD5363B943F2AE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>

Does anyone mind if:

 - reduce/remove support for Windows prior to Vista? (including Win95/Win98/NT4/Win2000/XP).
i.e. use __declspec(thread) (and continue to ignore fibers)
i.e. maybe use SRWLOCK and Win32 condition variable.

 - reduce/remove support for Visual C++ prior to 2015?
i.e. assume what we link to wrt msvcrt.lib/libmt.lib
i.e. remove the mt.exe support?
Config file stuff.

 - remove support for linking to static C runtime?
Config file stuff.

I'm torn on all of them.
The old systems weren't that bad to program against, and aren't that difficult, in some sense to support..well, easy code to write,
not at all easy to test, an ever expanding matrix, unless someone does a good job of automating it, or is commited
to active manual development/test with old.

On the other hand, NT 3.1, Win95, and Win32s shouldn't be all that difficult to support.

How portable should a portable runtime be?

By and large, industry does not support prior to Windows 7.

 - Related question then as to what to support bootstrapping from.
 3.6? 4.0? etc.

 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190527/50b05155/attachment.html>

From jayk123 at hotmail.com  Mon May 27 11:29:11 2019
From: jayk123 at hotmail.com (Jay K)
Date: Mon, 27 May 2019 09:29:11 +0000
Subject: [M3devel] CM3 IR for allocating local jmpbuf?
Message-ID: <BN8PR03MB4786E52CF4D42D589064EE3FE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>

Hi. The frontend has two ways to communicate to the backend allocation of a local jmp_buf.?
?
1.?
?
local with the right size and alignment?
?
2.?
local pointer initialized with alloca(a particular global)?,
that happens to be passed to setjmp?
?
?
The second pattern is the more common one these days.?
I changed it to that, which is slower, in order?
to remove target knowledge from the frontend.?
?
I still like that idea.?
?
However,?
?
1. Perhaps the optimization of the old way is worthwhile.?
Thoughts? Data??
?
2. I want a third way.?
?
I want the C backend to be able to say:?
?
#nclude <setjmp.h>?
?
void function()?
{?
 jmp_buf a;?
}?
?
with an actual literal "jmp_buf" for the type, to be resolved?
via the include of setjmp.h, by the C compiler.?
?
Kinda like the old option 1, but the generated C source is actually target-independent.?
?
Thoughts on how to best do that??
?
I could pattern match against form 2, but that seems a little gross.

Add to M3CG_Options declare_local_jmpbuf??
?
?
Granted, this is a stepping stone.?
I really want a higher level try/finally/catch/throw in the IR.?
?
The backend should be optionally synthesizing jmpbuf, setjmp, and longjmp?
should be up the library, in coordination with the backend?
?
?
The C (C++) backend should just be able to say try/catch/throw :)?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190527/faaa2764/attachment.html>

From peter.mckinna at gmail.com  Mon May 27 11:45:44 2019
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Mon, 27 May 2019 19:45:44 +1000
Subject: [M3devel] reducing support for old..?
In-Reply-To: <BN8PR03MB4786C6B7440FD5363B943F2AE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB4786C6B7440FD5363B943F2AE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <CAEy6uxrwOws0h_SD3cVU1SurBwBep-giWr_Fu_wfmX1Qf+9mGQ@mail.gmail.com>

Go for it.

Hasn't the world upgraded to Windows 10?

Simply as much as possible but no simpler, (to paraphrase Einstein)

Peter


On Mon, May 27, 2019 at 6:11 PM Jay K <jayk123 at hotmail.com> wrote:

> Does anyone mind if:
>
>  - reduce/remove support for Windows prior to Vista? (including
> Win95/Win98/NT4/Win2000/XP).
> i.e. use __declspec(thread) (and continue to ignore fibers)
> i.e. maybe use SRWLOCK and Win32 condition variable.
>
>  - reduce/remove support for Visual C++ prior to 2015?
> i.e. assume what we link to wrt msvcrt.lib/libmt.lib
> i.e. remove the mt.exe support?
> Config file stuff.
>
>  - remove support for linking to static C runtime?
> Config file stuff.
>
> I'm torn on all of them.
> The old systems weren't that bad to program against, and aren't that
> difficult, in some sense to support..well, easy code to write,
> not at all easy to test, an ever expanding matrix, unless someone does a
> good job of automating it, or is commited
> to active manual development/test with old.
>
> On the other hand, NT 3.1, Win95, and Win32s shouldn't be all that
> difficult to support.
>
> How portable should a portable runtime be?
>
> By and large, industry does not support prior to Windows 7.
>
>  - Related question then as to what to support bootstrapping from.
>  3.6? 4.0? etc.
>
>  - Jay
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190527/2d2482c1/attachment-0001.html>

From dmuysers at hotmail.com  Mon May 27 11:55:24 2019
From: dmuysers at hotmail.com (dirk muysers)
Date: Mon, 27 May 2019 09:55:24 +0000
Subject: [M3devel] reducing support for old..?
In-Reply-To: <CAEy6uxrwOws0h_SD3cVU1SurBwBep-giWr_Fu_wfmX1Qf+9mGQ@mail.gmail.com>
References: <BN8PR03MB4786C6B7440FD5363B943F2AE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <CAEy6uxrwOws0h_SD3cVU1SurBwBep-giWr_Fu_wfmX1Qf+9mGQ@mail.gmail.com>
Message-ID: <LNXP123MB208972363D6263229A3E1FAFDD1D0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>

People are reluctant to upgrade from Windows 7 to Windows 10, because the new version invades one's privacy. Microsoft thinks that your computer belongs to them, not to you, but --sorry-- enough politics.

On 27/05/2019 11:46:44, Peter McKinna <peter.mckinna at gmail.com> wrote:

Go for it.

Hasn't the world upgraded to Windows 10?

Simply as much as possible but no simpler, (to paraphrase Einstein)

Peter


On Mon, May 27, 2019 at 6:11 PM Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:
Does anyone mind if:

 - reduce/remove support for Windows prior to Vista? (including Win95/Win98/NT4/Win2000/XP).
i.e. use __declspec(thread) (and continue to ignore fibers)
i.e. maybe use SRWLOCK and Win32 condition variable.

 - reduce/remove support for Visual C++ prior to 2015?
i.e. assume what we link to wrt msvcrt.lib/libmt.lib
i.e. remove the mt.exe support?
Config file stuff.

 - remove support for linking to static C runtime?
Config file stuff.

I'm torn on all of them.
The old systems weren't that bad to program against, and aren't that difficult, in some sense to support..well, easy code to write,
not at all easy to test, an ever expanding matrix, unless someone does a good job of automating it, or is commited
to active manual development/test with old.

On the other hand, NT 3.1, Win95, and Win32s shouldn't be all that difficult to support.

How portable should a portable runtime be?

By and large, industry does not support prior to Windows 7.

 - Related question then as to what to support bootstrapping from.
 3.6? 4.0? etc.

 - Jay
_______________________________________________
M3devel mailing list
M3devel at elegosoft.com<mailto:M3devel at elegosoft.com>
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
_______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190527/1dbc8b38/attachment.html>

From jayk123 at hotmail.com  Mon May 27 14:06:24 2019
From: jayk123 at hotmail.com (Jay K)
Date: Mon, 27 May 2019 12:06:24 +0000
Subject: [M3devel] reducing support for old..?
In-Reply-To: <LNXP123MB208972363D6263229A3E1FAFDD1D0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
References: <BN8PR03MB4786C6B7440FD5363B943F2AE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <CAEy6uxrwOws0h_SD3cVU1SurBwBep-giWr_Fu_wfmX1Qf+9mGQ@mail.gmail.com>,
 <LNXP123MB208972363D6263229A3E1FAFDD1D0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <BN8PR03MB4786A83ECB697ECEE2715111E61D0@BN8PR03MB4786.namprd03.prod.outlook.com>

But I didn't say Windows 10:

 - reduce/remove support for Windows prior to Vista?

 - Jay

________________________________
From: dirk muysers <dmuysers at hotmail.com>
Sent: Monday, May 27, 2019 9:55 AM
To: Peter McKinna; Jay K
Cc: m3devel at elegosoft.com
Subject: Re: [M3devel] reducing support for old..?

People are reluctant to upgrade from Windows 7 to Windows 10, because the new version invades one's privacy. Microsoft thinks that your computer belongs to them, not to you, but --sorry-- enough politics.

On 27/05/2019 11:46:44, Peter McKinna <peter.mckinna at gmail.com> wrote:

Go for it.

Hasn't the world upgraded to Windows 10?

Simply as much as possible but no simpler, (to paraphrase Einstein)

Peter


On Mon, May 27, 2019 at 6:11 PM Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:
Does anyone mind if:

 - reduce/remove support for Windows prior to Vista? (including Win95/Win98/NT4/Win2000/XP).
i.e. use __declspec(thread) (and continue to ignore fibers)
i.e. maybe use SRWLOCK and Win32 condition variable.

 - reduce/remove support for Visual C++ prior to 2015?
i.e. assume what we link to wrt msvcrt.lib/libmt.lib
i.e. remove the mt.exe support?
Config file stuff.

 - remove support for linking to static C runtime?
Config file stuff.

I'm torn on all of them.
The old systems weren't that bad to program against, and aren't that difficult, in some sense to support..well, easy code to write,
not at all easy to test, an ever expanding matrix, unless someone does a good job of automating it, or is commited
to active manual development/test with old.

On the other hand, NT 3.1, Win95, and Win32s shouldn't be all that difficult to support.

How portable should a portable runtime be?

By and large, industry does not support prior to Windows 7.

 - Related question then as to what to support bootstrapping from.
 3.6? 4.0? etc.

 - Jay
_______________________________________________
M3devel mailing list
M3devel at elegosoft.com<mailto:M3devel at elegosoft.com>
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
_______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190527/7571b41a/attachment-0001.html>

From jayk123 at hotmail.com  Mon May 27 14:09:23 2019
From: jayk123 at hotmail.com (Jay K)
Date: Mon, 27 May 2019 12:09:23 +0000
Subject: [M3devel] m3 pull requests
Message-ID: <BN8PR03MB4786BDB5ECA40CD35B58C852E61D0@BN8PR03MB4786.namprd03.prod.outlook.com>

https://github.com/modula3/cm3/pull/54
https://github.com/modula3/cm3/pull/53
https://github.com/modula3/cm3/pull/52


some O self-approved and commited:


https://github.com/modula3/cm3/pull/51
https://github.com/modula3/cm3/pull/50 (maybe should restore whitespace, sorry, though my other git projects cover this up somehow, seemingly, on the server side)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190527/b91ef141/attachment.html>

From hendrik at topoi.pooq.com  Mon May 27 14:43:42 2019
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 27 May 2019 08:43:42 -0400
Subject: [M3devel] reducing support for old..?
In-Reply-To: <CAEy6uxrwOws0h_SD3cVU1SurBwBep-giWr_Fu_wfmX1Qf+9mGQ@mail.gmail.com>
References: <BN8PR03MB4786C6B7440FD5363B943F2AE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <CAEy6uxrwOws0h_SD3cVU1SurBwBep-giWr_Fu_wfmX1Qf+9mGQ@mail.gmail.com>
Message-ID: <20190527124342.ygomsj5ou35tcpyn@topoi.pooq.com>

On Mon, May 27, 2019 at 07:45:44PM +1000, Peter McKinna wrote:
> Go for it.
> 
> Hasn't the world upgraded to Windows 10?
> 
> Simply as much as possible but no simpler, (to paraphrase Einstein)
> 
> Peter

There are still a lot of systems still running XP, simply because their 
software doesn't  run on anything later.

-- hendrik

> 
> 
> On Mon, May 27, 2019 at 6:11 PM Jay K <jayk123 at hotmail.com> wrote:
> 
> > Does anyone mind if:
> >
> >  - reduce/remove support for Windows prior to Vista? (including
> > Win95/Win98/NT4/Win2000/XP).
> > i.e. use __declspec(thread) (and continue to ignore fibers)
> > i.e. maybe use SRWLOCK and Win32 condition variable.
> >
> >  - reduce/remove support for Visual C++ prior to 2015?
> > i.e. assume what we link to wrt msvcrt.lib/libmt.lib
> > i.e. remove the mt.exe support?
> > Config file stuff.
> >
> >  - remove support for linking to static C runtime?
> > Config file stuff.
> >
> > I'm torn on all of them.
> > The old systems weren't that bad to program against, and aren't that
> > difficult, in some sense to support..well, easy code to write,
> > not at all easy to test, an ever expanding matrix, unless someone does a
> > good job of automating it, or is commited
> > to active manual development/test with old.
> >
> > On the other hand, NT 3.1, Win95, and Win32s shouldn't be all that
> > difficult to support.
> >
> > How portable should a portable runtime be?
> >
> > By and large, industry does not support prior to Windows 7.
> >
> >  - Related question then as to what to support bootstrapping from.
> >  3.6? 4.0? etc.
> >
> >  - Jay
> > _______________________________________________
> > M3devel mailing list
> > M3devel at elegosoft.com
> > https://m3lists.elegosoft.com/mailman/listinfo/m3devel
> >

> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel


From hendrik at topoi.pooq.com  Mon May 27 14:46:16 2019
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 27 May 2019 08:46:16 -0400
Subject: [M3devel] CM3 IR for allocating local jmpbuf?
In-Reply-To: <BN8PR03MB4786E52CF4D42D589064EE3FE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB4786E52CF4D42D589064EE3FE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <20190527124616.z3sdv26vic45nqtu@topoi.pooq.com>

On Mon, May 27, 2019 at 09:29:11AM +0000, Jay K wrote:
> Hi. The frontend has two ways to communicate to the backend allocation of a local jmp_buf.?
> ?
> 1.?
> ?
> local with the right size and alignment?
> ?
> 2.?
> local pointer initialized with alloca(a particular global)?,
> that happens to be passed to setjmp?
> ?
> ?
> The second pattern is the more common one these days.?
> I changed it to that, which is slower, in order?
> to remove target knowledge from the frontend.?

alloa used to be a nonstandard feature, only available in some C 
implementations.  Has this changed?

-- hendrik

From jayk123 at hotmail.com  Mon May 27 20:18:13 2019
From: jayk123 at hotmail.com (Jay K)
Date: Mon, 27 May 2019 18:18:13 +0000
Subject: [M3devel] reducing support for old..?
In-Reply-To: <20190527124342.ygomsj5ou35tcpyn@topoi.pooq.com>
References: <BN8PR03MB4786C6B7440FD5363B943F2AE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <CAEy6uxrwOws0h_SD3cVU1SurBwBep-giWr_Fu_wfmX1Qf+9mGQ@mail.gmail.com>,
 <20190527124342.ygomsj5ou35tcpyn@topoi.pooq.com>
Message-ID: <BN8PR03MB47868B53986F82B61BFB135CE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>

And we need to provide up to date Modula-3 for them?
For how much longer?

 - Jay

________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Hendrik Boom <hendrik at topoi.pooq.com>
Sent: Monday, May 27, 2019 12:43 PM
To: m3devel at elegosoft.com
Subject: Re: [M3devel] reducing support for old..?

On Mon, May 27, 2019 at 07:45:44PM +1000, Peter McKinna wrote:
> Go for it.
>
> Hasn't the world upgraded to Windows 10?
>
> Simply as much as possible but no simpler, (to paraphrase Einstein)
>
> Peter

There are still a lot of systems still running XP, simply because their
software doesn't  run on anything later.

-- hendrik

>
>
> On Mon, May 27, 2019 at 6:11 PM Jay K <jayk123 at hotmail.com> wrote:
>
> > Does anyone mind if:
> >
> >  - reduce/remove support for Windows prior to Vista? (including
> > Win95/Win98/NT4/Win2000/XP).
> > i.e. use __declspec(thread) (and continue to ignore fibers)
> > i.e. maybe use SRWLOCK and Win32 condition variable.
> >
> >  - reduce/remove support for Visual C++ prior to 2015?
> > i.e. assume what we link to wrt msvcrt.lib/libmt.lib
> > i.e. remove the mt.exe support?
> > Config file stuff.
> >
> >  - remove support for linking to static C runtime?
> > Config file stuff.
> >
> > I'm torn on all of them.
> > The old systems weren't that bad to program against, and aren't that
> > difficult, in some sense to support..well, easy code to write,
> > not at all easy to test, an ever expanding matrix, unless someone does a
> > good job of automating it, or is commited
> > to active manual development/test with old.
> >
> > On the other hand, NT 3.1, Win95, and Win32s shouldn't be all that
> > difficult to support.
> >
> > How portable should a portable runtime be?
> >
> > By and large, industry does not support prior to Windows 7.
> >
> >  - Related question then as to what to support bootstrapping from.
> >  3.6? 4.0? etc.
> >
> >  - Jay
> > _______________________________________________
> > M3devel mailing list
> > M3devel at elegosoft.com
> > https://m3lists.elegosoft.com/mailman/listinfo/m3devel
> >

> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel

_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190527/4d1e9aac/attachment.html>

From jayk123 at hotmail.com  Mon May 27 20:23:18 2019
From: jayk123 at hotmail.com (Jay K)
Date: Mon, 27 May 2019 18:23:18 +0000
Subject: [M3devel] CM3 IR for allocating local jmpbuf?
In-Reply-To: <20190527124616.z3sdv26vic45nqtu@topoi.pooq.com>
References: <BN8PR03MB4786E52CF4D42D589064EE3FE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>,
 <20190527124616.z3sdv26vic45nqtu@topoi.pooq.com>
Message-ID: <BN8PR03MB4786B66A41F44700FC09DE1FE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>

It is true that alloca is non-standard, however

The use outside of the C backend does not involve C.

It is really incredibly portable, even if not standard.
We are only using it for a small size.
I do propose not using it in the C backend. My interest
is more efficiency, but standard conformance would come
along as well.

 - Jay

________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Hendrik Boom <hendrik at topoi.pooq.com>
Sent: Monday, May 27, 2019 12:46 PM
To: m3devel at elegosoft.com
Subject: Re: [M3devel] CM3 IR for allocating local jmpbuf?

On Mon, May 27, 2019 at 09:29:11AM +0000, Jay K wrote:
> Hi. The frontend has two ways to communicate to the backend allocation of a local jmp_buf.?
> ?
> 1.?
> ?
> local with the right size and alignment?
> ?
> 2.?
> local pointer initialized with alloca(a particular global)?,
> that happens to be passed to setjmp?
> ?
> ?
> The second pattern is the more common one these days.?
> I changed it to that, which is slower, in order?
> to remove target knowledge from the frontend.?

alloa used to be a nonstandard feature, only available in some C
implementations.  Has this changed?

-- hendrik
_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190527/cc2ae06d/attachment-0001.html>

From hendrik at topoi.pooq.com  Tue May 28 00:31:16 2019
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Mon, 27 May 2019 18:31:16 -0400
Subject: [M3devel] reducing support for old..?
In-Reply-To: <BN8PR03MB47868B53986F82B61BFB135CE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB4786C6B7440FD5363B943F2AE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <CAEy6uxrwOws0h_SD3cVU1SurBwBep-giWr_Fu_wfmX1Qf+9mGQ@mail.gmail.com>
 <20190527124342.ygomsj5ou35tcpyn@topoi.pooq.com>
 <BN8PR03MB47868B53986F82B61BFB135CE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <20190527223115.gv2fcv74hvsikfm5@topoi.pooq.com>

On Mon, May 27, 2019 at 06:18:13PM +0000, Jay K wrote:
> And we need to provide up to date Modula-3 for them? For how much 
> longer?
> 
>  - Jay

I suspect providing a Modula 3 that's as obsolete as XP will work best 
for them.

-- hendrik

From dmuysers at hotmail.com  Tue May 28 16:31:41 2019
From: dmuysers at hotmail.com (dirk muysers)
Date: Tue, 28 May 2019 14:31:41 +0000
Subject: [M3devel] Windows with MS BuildTool
Message-ID: <LNXP123MB20892AE3A6FBFA391AECF2C9DD1E0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>

Continuing my attempt  to compile for X86 on my amd64 host, I removed every remaining trace of past Visual Studio versions by uninstalling everything and removing the corresponding environment variables.
I am now left with the MS Visual Studio BuildTool 2019 alone.

Trying to compile, I get now:
    C:\Users\Dirk\Dropbox\projects\libum3\tools\maketables\src>cm3
     --- building in ..\NT386 ---
     -> linking Maketables.exe
     cl.exe -nologo -DWIN32 -Zl  -Z7 -MD -Oi -c _m3main.c -Fo_m3main.obj
     _m3main.c
     _m3main.c(1): fatal error C1034: stddef.h: no include path set
     compile_c => 2
     C compiler failed compiling: _m3main.c
     Fatal Error: cc _m3main.c failed!!

The MS compiler being intended primarily for C++ where the some  "stddef.h" procedures are implemented as macros,
one must include instead include "cstddef.h". I corrected "_m3main.c" manually, but that doesn't work as the quake machinery
rebuilds it at every invocation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190528/0851532a/attachment.html>

From rodney_bates at lcwb.coop  Tue May 28 16:56:57 2019
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 28 May 2019 09:56:57 -0500
Subject: [M3devel] -boot and C backend broken by LLVM?
In-Reply-To: <BN8PR03MB47862329A9135027C58623C2E61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB4786A48F68FE5D2B93F449C6E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <BN8PR03MB478639DB07EF9FEEAC183952E61C0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <BN8PR03MB47862329A9135027C58623C2E61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <eafe05cd-860e-9e2c-dc7f-36591c8c9e43@lcwb.coop>



On 05/27/2019 02:34 AM, Jay K wrote:
> Oh, sorry, maybe it works.
> I can get all the .c files out and compile and link, and crash. Will investigate more..
> 
>  ? - Jay
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* M3devel <m3devel-bounces at elegosoft.com> on behalf of Jay K <jayk123 at hotmail.com>
> *Sent:* Sunday, May 26, 2019 9:43 PM
> *To:* m3devel; rodney.m.bates at acm.org
> *Subject:* Re: [M3devel] -boot and C backend broken by LLVM?
> I think in particular PushOneM3 got replaced. ?
> I'll keep looking at it..
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Jay K
> *Sent:* Sunday, May 26, 2019 9:13 PM
> *To:* m3devel; rodney.m.bates at acm.org
> *Subject:* -boot and C backend broken by LLVM?
> I'm pretty sure the merging of the LLVM builder support circa 2015 broke C backend with -boot.
> This is e.g. how you start with AMD64_NT. Well, other than an existing distribution.
> 
> The pattern of commenting out large functions, marking them "original" and making new ones nearby is kinda harmful.
> 
> I'll try to fix it.
> 
> I find the builder to be a bit of spaghetti code but maybe I just lack context.

Having been into it, I agree it's confusing.  But given the fundamental complexity
of the task, I'm not sure it could be made less so.

> 
>  ?- Jay
> 
> 
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
> 

-- 
Rodney Bates
rodney.m.bates at acm.org

From rodney_bates at lcwb.coop  Wed May 29 03:29:45 2019
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 28 May 2019 20:29:45 -0500
Subject: [M3devel] Finding static areas
Message-ID: <ee4971df-694a-7433-6b78-4876b980daa4@lcwb.coop>


Anybody know how to get the address ranges of the static constant and static
writable areas of the executing linked program?
-- 
Rodney Bates
rodney.m.bates at acm.org

From dragisha at m3w.org  Wed May 29 16:25:20 2019
From: dragisha at m3w.org (Dragisa Duric)
Date: Wed, 29 May 2019 16:25:20 +0200
Subject: [M3devel] Finding static areas
In-Reply-To: <ee4971df-694a-7433-6b78-4876b980daa4@lcwb.coop>
References: <ee4971df-694a-7433-6b78-4876b980daa4@lcwb.coop>
Message-ID: <0a21ea374646541d3a4540f3c7c9d00e1a3b6c37.camel@m3w.org>

On Tue, 2019-05-28 at 20:29 -0500, Rodney M. Bates wrote:
> Anybody know how to get the address ranges of the static constant and
> static
> writable areas of the executing linked program?

If I understand this correctly the I think you may find idea on
location static writable areas in garbage collector code... Final
phases of collection consults global variable spaces. PRobably this
will also give a hint for static constant area.


From jayk123 at hotmail.com  Thu May 30 00:23:38 2019
From: jayk123 at hotmail.com (Jay K)
Date: Wed, 29 May 2019 22:23:38 +0000
Subject: [M3devel] Finding static areas
In-Reply-To: <0a21ea374646541d3a4540f3c7c9d00e1a3b6c37.camel@m3w.org>
References: <ee4971df-694a-7433-6b78-4876b980daa4@lcwb.coop>,
 <0a21ea374646541d3a4540f3c7c9d00e1a3b6c37.camel@m3w.org>
Message-ID: <BN8PR03MB478625154CE6FF3D109A98BFE61F0@BN8PR03MB4786.namprd03.prod.outlook.com>

Why? What would you do with such information?

On Linux and maybe other systems there are special global variables for this, etext and such.
I saw them used in profiling code.
But in general there can be multiple such regions, and they can interleave.
The Linux variables I think are deprecated.

VirtualQuery on Windows is kinda helpful, but more efficiently you can just parse your own PE headers, starting with the linker special symbol __ImageBase.

 - Jay

________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Dragisa Duric <dragisha at m3w.org>
Sent: Wednesday, May 29, 2019 2:25 PM
To: rodney.m.bates at acm.org; m3devel
Subject: Re: [M3devel] Finding static areas

On Tue, 2019-05-28 at 20:29 -0500, Rodney M. Bates wrote:
> Anybody know how to get the address ranges of the static constant and
> static
> writable areas of the executing linked program?

If I understand this correctly the I think you may find idea on
location static writable areas in garbage collector code... Final
phases of collection consults global variable spaces. PRobably this
will also give a hint for static constant area.

_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190529/848ef857/attachment-0001.html>

From rodney_bates at lcwb.coop  Thu May 30 03:32:47 2019
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 29 May 2019 20:32:47 -0500
Subject: [M3devel] Finding static areas
In-Reply-To: <BN8PR03MB478625154CE6FF3D109A98BFE61F0@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <ee4971df-694a-7433-6b78-4876b980daa4@lcwb.coop>
 <0a21ea374646541d3a4540f3c7c9d00e1a3b6c37.camel@m3w.org>
 <BN8PR03MB478625154CE6FF3D109A98BFE61F0@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <78e3d04e-4971-1ce5-422d-57ef5dcdb5e8@lcwb.coop>



On 05/29/2019 05:23 PM, Jay K wrote:
> Why? What would you do with such information?
> 

I'm writing tests of compiler generation of array constructors.  I
want to verify where dope is constructed: global area, on stack,
etc.

> On Linux and maybe other systems there are special global variables for this, etext and such.
> I saw them used in profiling code.
> But in general there can be multiple such regions, and they can interleave.
> The Linux variables I think are deprecated.
> 
> VirtualQuery on Windows is kinda helpful, but more efficiently you can just parse your own PE headers, starting with the linker special symbol __ImageBase.
> 
>  ?- Jay
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* M3devel <m3devel-bounces at elegosoft.com> on behalf of Dragisa Duric <dragisha at m3w.org>
> *Sent:* Wednesday, May 29, 2019 2:25 PM
> *To:* rodney.m.bates at acm.org; m3devel
> *Subject:* Re: [M3devel] Finding static areas
> On Tue, 2019-05-28 at 20:29 -0500, Rodney M. Bates wrote:
>> Anybody know how to get the address ranges of the static constant and
>> static
>> writable areas of the executing linked program?
> 
> If I understand this correctly the I think you may find idea on
> location static writable areas in garbage collector code... Final
> phases of collection consults global variable spaces. PRobably this
> will also give a hint for static constant area.
> 
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel

-- 
Rodney Bates
rodney.m.bates at acm.org

From jayk123 at hotmail.com  Thu May 30 03:46:28 2019
From: jayk123 at hotmail.com (Jay K)
Date: Thu, 30 May 2019 01:46:28 +0000
Subject: [M3devel] Finding static areas
In-Reply-To: <78e3d04e-4971-1ce5-422d-57ef5dcdb5e8@lcwb.coop>
References: <ee4971df-694a-7433-6b78-4876b980daa4@lcwb.coop>
 <0a21ea374646541d3a4540f3c7c9d00e1a3b6c37.camel@m3w.org>
 <BN8PR03MB478625154CE6FF3D109A98BFE61F0@BN8PR03MB4786.namprd03.prod.outlook.com>,
 <78e3d04e-4971-1ce5-422d-57ef5dcdb5e8@lcwb.coop>
Message-ID: <BN8PR03MB4786AEAE2D2ECDBD133C5E69E6180@BN8PR03MB4786.namprd03.prod.outlook.com>

Windows: GetCurrentThreadStackLimits and range check to see if something is in stack.
Windows: VirtualQuery to see if something is readonly or writable.

Windows is strict about where the stack is. Because of guard pages and exception handling sanity checking, etc.
Unix lets you just malloc and set rsp and everyone pretends exceptions don't exist, so languages cannot interp.
So it can be anywhere.

For the current code's .data and .rdata, or enumerating each of them, that is pretty easy.
Or you could VirtualQuery against some reaodnly and writable globals.

I think you'll find it is easy to get this correct though.
The "segment" stuff.

Modula-3 also goes out of its way to..kinda defeat the linker, and the native debugger.
The globals are all smushed together into per-module opaque globals. I guess they are called "segments".
So unused data cannot be removed by a nice optimizing linker.
And layout is known for garbage collection purposes, w/o a relocation per global.
Another design might be to leave each data item "loose", but take the address of GC roots, and collect those into a findable place.
And then the take-address will keepalive -- what you really want, and linkers do support this -- is that the address-taken does not keep alive what it refers to, but the other way around.
The referred to item has its own linker-decided lifetime, and if it is alive, it will bring in the address-taker or whatever GC data.

The Visual C++ compiler/linker have this "associative symbol" feature.
The "weak reference" part you would implement by putting the address-taken into a separate .obj.
So each global that needs GC data would be "associated with" its GC data.
You'd get both or neither.
Maybe some day..

But we'd also have to see if ELF and Macho have these features.

If you look at the ancient Win32 import lib format from circa 1996, you can see this in action.
The null terminals for the various data structures are "associated" with the array elements.
Similarly, there are parallel arrays in the data structures.
One array is actually referenced, and the other is associated.
Sorry this probably doesn't make sense w/o more explanation and is tangential.

 - Jay

________________________________
From: Rodney M. Bates <rodney_bates at lcwb.coop>
Sent: Thursday, May 30, 2019 1:32 AM
To: Jay K; Dragisa Duric; rodney.m.bates at acm.org; m3devel
Subject: Re: [M3devel] Finding static areas



On 05/29/2019 05:23 PM, Jay K wrote:
> Why? What would you do with such information?
>

I'm writing tests of compiler generation of array constructors.  I
want to verify where dope is constructed: global area, on stack,
etc.

> On Linux and maybe other systems there are special global variables for this, etext and such.
> I saw them used in profiling code.
> But in general there can be multiple such regions, and they can interleave.
> The Linux variables I think are deprecated.
>
> VirtualQuery on Windows is kinda helpful, but more efficiently you can just parse your own PE headers, starting with the linker special symbol __ImageBase.
>
>   - Jay
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* M3devel <m3devel-bounces at elegosoft.com> on behalf of Dragisa Duric <dragisha at m3w.org>
> *Sent:* Wednesday, May 29, 2019 2:25 PM
> *To:* rodney.m.bates at acm.org; m3devel
> *Subject:* Re: [M3devel] Finding static areas
> On Tue, 2019-05-28 at 20:29 -0500, Rodney M. Bates wrote:
>> Anybody know how to get the address ranges of the static constant and
>> static
>> writable areas of the executing linked program?
>
> If I understand this correctly the I think you may find idea on
> location static writable areas in garbage collector code... Final
> phases of collection consults global variable spaces. PRobably this
> will also give a hint for static constant area.
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel

--
Rodney Bates
rodney.m.bates at acm.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190530/f8a503ec/attachment.html>

From rodney_bates at lcwb.coop  Fri May 31 03:20:08 2019
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 30 May 2019 20:20:08 -0500
Subject: [M3devel] Finding static areas
In-Reply-To: <BN8PR03MB4786AEAE2D2ECDBD133C5E69E6180@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <ee4971df-694a-7433-6b78-4876b980daa4@lcwb.coop>
 <0a21ea374646541d3a4540f3c7c9d00e1a3b6c37.camel@m3w.org>
 <BN8PR03MB478625154CE6FF3D109A98BFE61F0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <78e3d04e-4971-1ce5-422d-57ef5dcdb5e8@lcwb.coop>
 <BN8PR03MB4786AEAE2D2ECDBD133C5E69E6180@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <da260ff0-ab3e-922d-ce6f-32ad5b093198@lcwb.coop>



On 05/29/2019 08:46 PM, Jay K wrote:
> Windows:?GetCurrentThreadStackLimits and range check to see if something is in stack.
> Windows: VirtualQuery to see if something is readonly or writable.
> 
> Windows is strict about where the stack is. Because of guard pages and exception handling sanity checking, etc.
> Unix lets you just malloc and set rsp and everyone pretends exceptions don't exist, so languages cannot interp.
> So it can be anywhere.
> 

I am getting stack range quite easily enough by just taking addresses of
local variables.

> For the current code's .data and .rdata, or enumerating each of them, that is pretty easy.
> Or you could VirtualQuery against some reaodnly and writable globals.
> 
> I think you'll find it is easy to get this correct though.
> The "segment" stuff.

Here's my thinking on segments.
Every separate compilation needs the ability to allocate its own stuff in
in static readonly (similarly, static read-write areas BTW), which it puts
in a segments  A traditional linker usually combines all these contiguously,
so that hardware memory protection can be applied without major fragmentation.
I don't know of any way to control or even know what order the constant segments
from the many separate compilations are laid out in.

Moreover, I can't take the address of a declared global constant, because a
constant is, by language definition, never a designator, even if the compiler
were to put it in memory, as is in general almost certain for an array, and
certainly what CM3 does.

I am thinking there must be some pointers inside the RTS, but it's a lot to comb
through, and no luck so far.  I was hoping somebody would just happen to
know where.

> 
> Modula-3 also goes out of its way to..kinda defeat the linker, and the native debugger.
> The globals are all smushed together into per-module opaque globals. I guess they are called "segments".
> So unused data cannot be removed by a nice optimizing linker.
> And layout is known for garbage collection purposes, w/o a relocation per global.
> Another design might be to leave each data item "loose", but take the address of GC roots, and collect those into a findable place.
> And then the take-address will keepalive -- what you really want, and linkers do support this -- is that the address-taken does not keep alive what it refers to, but the other way around.
> The referred to item has its own linker-decided lifetime, and if it is alive, it will bring in the address-taker or whatever GC data.
> 
> The Visual C++ compiler/linker have this "associative symbol" feature.
> The "weak reference" part you would implement by putting the address-taken into a separate .obj.
> So each global that needs GC data would be "associated with" its GC data.
> You'd get both or neither.
> Maybe some day..
> 
> But we'd also have to see if ELF and Macho have these features.
> 
> If you look at the ancient Win32 import lib format from circa 1996, you can see this in action.
> The null terminals for the various data structures are "associated" with the array elements.
> Similarly, there are parallel arrays in the data structures.
> One array is actually referenced, and the other is associated.
> Sorry this probably doesn't make sense w/o more explanation and is tangential.
> 
>  ?- Jay
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Rodney M. Bates <rodney_bates at lcwb.coop>
> *Sent:* Thursday, May 30, 2019 1:32 AM
> *To:* Jay K; Dragisa Duric; rodney.m.bates at acm.org; m3devel
> *Subject:* Re: [M3devel] Finding static areas
> 
> 
> On 05/29/2019 05:23 PM, Jay K wrote:
>> Why? What would you do with such information?
>> 
> 
> I'm writing tests of compiler generation of array constructors.? I
> want to verify where dope is constructed: global area, on stack,
> etc.
> 
>> On Linux and maybe other systems there are special global variables for this, etext and such.
>> I saw them used in profiling code.
>> But in general there can be multiple such regions, and they can interleave.
>> The Linux variables I think are deprecated.
>> 
>> VirtualQuery on Windows is kinda helpful, but more efficiently you can just parse your own PE headers, starting with the linker special symbol __ImageBase.
>> 
>>? ?- Jay
>> 
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> *From:* M3devel <m3devel-bounces at elegosoft.com> on behalf of Dragisa Duric <dragisha at m3w.org>
>> *Sent:* Wednesday, May 29, 2019 2:25 PM
>> *To:* rodney.m.bates at acm.org; m3devel
>> *Subject:* Re: [M3devel] Finding static areas
>> On Tue, 2019-05-28 at 20:29 -0500, Rodney M. Bates wrote:
>>> Anybody know how to get the address ranges of the static constant and
>>> static
>>> writable areas of the executing linked program?
>> 
>> If I understand this correctly the I think you may find idea on
>> location static writable areas in garbage collector code... Final
>> phases of collection consults global variable spaces. PRobably this
>> will also give a hint for static constant area.
>> 
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org

-- 
Rodney Bates
rodney.m.bates at acm.org

From jayk123 at hotmail.com  Fri May 31 11:56:57 2019
From: jayk123 at hotmail.com (Jay K)
Date: Fri, 31 May 2019 09:56:57 +0000
Subject: [M3devel] cm3 -D order vs. config file?
Message-ID: <BN8PR03MB47861192CE40C0FB1CA64118E6190@BN8PR03MB4786.namprd03.prod.outlook.com>

%
% Unfortunately, command line defines are not currently?
% available to the toplevel cm3.cfg.?
%?
?
?
This seems really broken to me.?
At least from a Windows point of view.?
?
So you can't say easy things like:?
?
cm3 -DTARGET=AMD64_NT -DROOT=c:/s/cm3?
?
Instead you have to, environment instead:?
?
set CM3_TARGET=x?
set CM3_ROOT=y?
cm3?
?
or Unix not as bad, somewhat more isomorphic:
?
CM3_TARGET=x CM3_ROOT=y cm3?

Ok if I try to fix it?
I thought I had.
Maybe I was using an old build to bootstrap..
?
?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190531/dee40198/attachment.html>

From vvm at tut.by  Fri May 31 12:55:35 2019
From: vvm at tut.by (vvm at tut.by)
Date: Fri, 31 May 2019 13:55:35 +0300
Subject: [M3devel] cm3 -D order vs. config file?
In-Reply-To: <BN8PR03MB47861192CE40C0FB1CA64118E6190@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB47861192CE40C0FB1CA64118E6190@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <1018801559300135@myt5-02b80404fd9e.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190531/9fe8c6d5/attachment.html>

From jayk123 at hotmail.com  Fri May 31 19:31:44 2019
From: jayk123 at hotmail.com (Jay K)
Date: Fri, 31 May 2019 17:31:44 +0000
Subject: [M3devel] calltech parser memory?
Message-ID: <BN8PR03MB478676962B74A9259005DE5FE6190@BN8PR03MB4786.namprd03.prod.outlook.com>

 +++ c:\cm3\bin\cm3.exe    -build -DROOT=C:/s/cm3 +++
--- building in NT386 ---?
?
ignoring ..\src\m3overrides?
?
C:/s/cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
?
?
***?
*** runtime error:?
***    NEW() was unable to allocate more memory.?
***    file "..\src\runtime\common\RuntimeError.m3", line 63?
***?
?
?
?
***?
*** runtime error:?
***    <*ASSERT*> failed.?
***    file "..\src\runtime\common\RTCollector.m3", line 591?
***?
?
Stack trace:?
   FP         PC      Procedure?
---------  ---------  -------------------------------?
 0x5af93c   0xf24f13  DefaultBackstop + 0xe3 in ..\src\runtime\common\RTException.m3?
.........  .........  ... more frames ...?
"c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
?
--procedure--  -line-  -file---?
exec               --  <builtin>?
_exec              37  c:\cm3\pkg\cit_util\src\generics.tmpl?
_xCons             37  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pCons             97  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pConsUn           99  c:\cm3\pkg\parserlib\src\parser.tmpl?
parser            101  c:\cm3\pkg\parserlib\src\parser.tmpl?
include_dir         6  C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile?
                    5  C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args?
?
Fatal Error: package build failed?
 *** execution of [<function _BuildGlobalFunction at 0x0000000003280F28>, <function _ShipFunction at 0x0000000003280F98>] failed ***?
?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190531/fa689a88/attachment.html>

From jayk123 at hotmail.com  Fri May 31 19:53:21 2019
From: jayk123 at hotmail.com (Jay K)
Date: Fri, 31 May 2019 17:53:21 +0000
Subject: [M3devel] calltech parser memory?
In-Reply-To: <BN8PR03MB478676962B74A9259005DE5FE6190@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB478676962B74A9259005DE5FE6190@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <BN8PR03MB478651C2CE1673BB883CAD0CE6190@BN8PR03MB4786.namprd03.prod.outlook.com>

Another similar, more of a stack this time:

C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3
?
?
***?
*** runtime error:?
***    <*ASSERT*> failed.?
***    file "..\src\runtime\common\RTCollector.m3", line 591?
***?
?
Stack trace:?
   FP         PC      Procedure?
---------  ---------  -------------------------------?
 0xb4f1e4   0x1ce355  GrayBetween + 0x47 in ..\src\runtime\common\RTCollector.m3?
 0xb4f210   0x1ce1fe  PromotePage + 0x261 in ..\src\runtime\common\RTCollector.m3?
 0xb4f258   0x1cdd72  Move + 0x293 in ..\src\runtime\common\RTCollector.m3?
 0xb4f29c   0x1f8bcc  Walk + 0x448 in ..\src\runtime\common\RTHeapMap.m3?
 0xb4f2c0   0x1f84cf  DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3?
 0xb4f2ec   0x1f8465  WalkRef + 0xf5 in ..\src\runtime\common\RTHeapMap.m3?
 0xb4f31c   0x1cf6cc  CleanBetween + 0x137 in ..\src\runtime\common\RTCollector.m3?
 0xb4f354   0x1cf3bd  CopySome + 0x5e in ..\src\runtime\common\RTCollector.m3?
 0xb4f360   0x1cef1b  CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3?
 0xb4f370   0x1ce8ef  CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3?
.........  .........  ... more frames ...?
"c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
?
--procedure--  -line-  -file---?
exec               --  <builtin>?
_exec              37  c:\cm3\pkg\cit_util\src\generics.tmpl?
_xCons             37  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pCons             97  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pConsUn           99  c:\cm3\pkg\parserlib\src\parser.tmpl?
parser            101  c:\cm3\pkg\parserlib\src\parser.tmpl?
include_dir         6  C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile?
                    5  C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args?


 - Jay

________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Jay K <jayk123 at hotmail.com>
Sent: Friday, May 31, 2019 5:31 PM
To: m3devel
Subject: [M3devel] calltech parser memory?

 +++ c:\cm3\bin\cm3.exe    -build -DROOT=C:/s/cm3 +++
--- building in NT386 ---?
?
ignoring ..\src\m3overrides?
?
C:/s/cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
?
?
***?
*** runtime error:?
***    NEW() was unable to allocate more memory.?
***    file "..\src\runtime\common\RuntimeError.m3", line 63?
***?
?
?
?
***?
*** runtime error:?
***    <*ASSERT*> failed.?
***    file "..\src\runtime\common\RTCollector.m3", line 591?
***?
?
Stack trace:?
   FP         PC      Procedure?
---------  ---------  -------------------------------?
 0x5af93c   0xf24f13  DefaultBackstop + 0xe3 in ..\src\runtime\common\RTException.m3?
.........  .........  ... more frames ...?
"c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
?
--procedure--  -line-  -file---?
exec               --  <builtin>?
_exec              37  c:\cm3\pkg\cit_util\src\generics.tmpl?
_xCons             37  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pCons             97  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pConsUn           99  c:\cm3\pkg\parserlib\src\parser.tmpl?
parser            101  c:\cm3\pkg\parserlib\src\parser.tmpl?
include_dir         6  C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile?
                    5  C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args?
?
Fatal Error: package build failed?
 *** execution of [<function _BuildGlobalFunction at 0x0000000003280F28>, <function _ShipFunction at 0x0000000003280F98>] failed ***?
?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190531/4dad0cac/attachment-0001.html>

From jayk123 at hotmail.com  Fri May 31 19:53:56 2019
From: jayk123 at hotmail.com (Jay K)
Date: Fri, 31 May 2019 17:53:56 +0000
Subject: [M3devel] calltech parser memory?
In-Reply-To: <BN8PR03MB478651C2CE1673BB883CAD0CE6190@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB478676962B74A9259005DE5FE6190@BN8PR03MB4786.namprd03.prod.outlook.com>,
 <BN8PR03MB478651C2CE1673BB883CAD0CE6190@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <BN8PR03MB4786EDF5FEBB867B65B2F347E6190@BN8PR03MB4786.namprd03.prod.outlook.com>

Actually this doesn't say out of memory, bug maybe bug in GC?
@Tony<mailto:hosking at cs.purdue.edu>

________________________________
From: Jay K
Sent: Friday, May 31, 2019 5:53 PM
To: m3devel
Subject: Re: calltech parser memory?

Another similar, more of a stack this time:

C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3
?
?
***?
*** runtime error:?
***    <*ASSERT*> failed.?
***    file "..\src\runtime\common\RTCollector.m3", line 591?
***?
?
Stack trace:?
   FP         PC      Procedure?
---------  ---------  -------------------------------?
 0xb4f1e4   0x1ce355  GrayBetween + 0x47 in ..\src\runtime\common\RTCollector.m3?
 0xb4f210   0x1ce1fe  PromotePage + 0x261 in ..\src\runtime\common\RTCollector.m3?
 0xb4f258   0x1cdd72  Move + 0x293 in ..\src\runtime\common\RTCollector.m3?
 0xb4f29c   0x1f8bcc  Walk + 0x448 in ..\src\runtime\common\RTHeapMap.m3?
 0xb4f2c0   0x1f84cf  DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3?
 0xb4f2ec   0x1f8465  WalkRef + 0xf5 in ..\src\runtime\common\RTHeapMap.m3?
 0xb4f31c   0x1cf6cc  CleanBetween + 0x137 in ..\src\runtime\common\RTCollector.m3?
 0xb4f354   0x1cf3bd  CopySome + 0x5e in ..\src\runtime\common\RTCollector.m3?
 0xb4f360   0x1cef1b  CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3?
 0xb4f370   0x1ce8ef  CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3?
.........  .........  ... more frames ...?
"c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
?
--procedure--  -line-  -file---?
exec               --  <builtin>?
_exec              37  c:\cm3\pkg\cit_util\src\generics.tmpl?
_xCons             37  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pCons             97  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pConsUn           99  c:\cm3\pkg\parserlib\src\parser.tmpl?
parser            101  c:\cm3\pkg\parserlib\src\parser.tmpl?
include_dir         6  C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile?
                    5  C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args?


 - Jay

________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Jay K <jayk123 at hotmail.com>
Sent: Friday, May 31, 2019 5:31 PM
To: m3devel
Subject: [M3devel] calltech parser memory?

 +++ c:\cm3\bin\cm3.exe    -build -DROOT=C:/s/cm3 +++
--- building in NT386 ---?
?
ignoring ..\src\m3overrides?
?
C:/s/cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
?
?
***?
*** runtime error:?
***    NEW() was unable to allocate more memory.?
***    file "..\src\runtime\common\RuntimeError.m3", line 63?
***?
?
?
?
***?
*** runtime error:?
***    <*ASSERT*> failed.?
***    file "..\src\runtime\common\RTCollector.m3", line 591?
***?
?
Stack trace:?
   FP         PC      Procedure?
---------  ---------  -------------------------------?
 0x5af93c   0xf24f13  DefaultBackstop + 0xe3 in ..\src\runtime\common\RTException.m3?
.........  .........  ... more frames ...?
"c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
?
--procedure--  -line-  -file---?
exec               --  <builtin>?
_exec              37  c:\cm3\pkg\cit_util\src\generics.tmpl?
_xCons             37  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pCons             97  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pConsUn           99  c:\cm3\pkg\parserlib\src\parser.tmpl?
parser            101  c:\cm3\pkg\parserlib\src\parser.tmpl?
include_dir         6  C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile?
                    5  C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args?
?
Fatal Error: package build failed?
 *** execution of [<function _BuildGlobalFunction at 0x0000000003280F28>, <function _ShipFunction at 0x0000000003280F98>] failed ***?
?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190531/c0a4afb5/attachment.html>

From jayk123 at hotmail.com  Fri May 31 19:56:04 2019
From: jayk123 at hotmail.com (Jay K)
Date: Fri, 31 May 2019 17:56:04 +0000
Subject: [M3devel] calltech parser memory?
In-Reply-To: <BN8PR03MB4786EDF5FEBB867B65B2F347E6190@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB478676962B74A9259005DE5FE6190@BN8PR03MB4786.namprd03.prod.outlook.com>,
 <BN8PR03MB478651C2CE1673BB883CAD0CE6190@BN8PR03MB4786.namprd03.prod.outlook.com>,
 <BN8PR03MB4786EDF5FEBB867B65B2F347E6190@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <BN8PR03MB4786ADAADA07B910DC3A3EC1E6190@BN8PR03MB4786.namprd03.prod.outlook.com>

Speaking of which, NT386, there is long-known bug.
I'll try to fix soon.
SuspendThread + GetThreadContext don't actually work reliably, on wow64, w/o checking some flags and sleep/retry.

 - Jay

________________________________
From: Jay K
Sent: Friday, May 31, 2019 5:53 PM
To: m3devel; Tony
Subject: Re: calltech parser memory?

Actually this doesn't say out of memory, bug maybe bug in GC?
@Tony<mailto:hosking at cs.purdue.edu>

________________________________
From: Jay K
Sent: Friday, May 31, 2019 5:53 PM
To: m3devel
Subject: Re: calltech parser memory?

Another similar, more of a stack this time:

C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3
?
?
***?
*** runtime error:?
***    <*ASSERT*> failed.?
***    file "..\src\runtime\common\RTCollector.m3", line 591?
***?
?
Stack trace:?
   FP         PC      Procedure?
---------  ---------  -------------------------------?
 0xb4f1e4   0x1ce355  GrayBetween + 0x47 in ..\src\runtime\common\RTCollector.m3?
 0xb4f210   0x1ce1fe  PromotePage + 0x261 in ..\src\runtime\common\RTCollector.m3?
 0xb4f258   0x1cdd72  Move + 0x293 in ..\src\runtime\common\RTCollector.m3?
 0xb4f29c   0x1f8bcc  Walk + 0x448 in ..\src\runtime\common\RTHeapMap.m3?
 0xb4f2c0   0x1f84cf  DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3?
 0xb4f2ec   0x1f8465  WalkRef + 0xf5 in ..\src\runtime\common\RTHeapMap.m3?
 0xb4f31c   0x1cf6cc  CleanBetween + 0x137 in ..\src\runtime\common\RTCollector.m3?
 0xb4f354   0x1cf3bd  CopySome + 0x5e in ..\src\runtime\common\RTCollector.m3?
 0xb4f360   0x1cef1b  CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3?
 0xb4f370   0x1ce8ef  CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3?
.........  .........  ... more frames ...?
"c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
?
--procedure--  -line-  -file---?
exec               --  <builtin>?
_exec              37  c:\cm3\pkg\cit_util\src\generics.tmpl?
_xCons             37  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pCons             97  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pConsUn           99  c:\cm3\pkg\parserlib\src\parser.tmpl?
parser            101  c:\cm3\pkg\parserlib\src\parser.tmpl?
include_dir         6  C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile?
                    5  C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args?


 - Jay

________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Jay K <jayk123 at hotmail.com>
Sent: Friday, May 31, 2019 5:31 PM
To: m3devel
Subject: [M3devel] calltech parser memory?

 +++ c:\cm3\bin\cm3.exe    -build -DROOT=C:/s/cm3 +++
--- building in NT386 ---?
?
ignoring ..\src\m3overrides?
?
C:/s/cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
?
?
***?
*** runtime error:?
***    NEW() was unable to allocate more memory.?
***    file "..\src\runtime\common\RuntimeError.m3", line 63?
***?
?
?
?
***?
*** runtime error:?
***    <*ASSERT*> failed.?
***    file "..\src\runtime\common\RTCollector.m3", line 591?
***?
?
Stack trace:?
   FP         PC      Procedure?
---------  ---------  -------------------------------?
 0x5af93c   0xf24f13  DefaultBackstop + 0xe3 in ..\src\runtime\common\RTException.m3?
.........  .........  ... more frames ...?
"c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3?
?
--procedure--  -line-  -file---?
exec               --  <builtin>?
_exec              37  c:\cm3\pkg\cit_util\src\generics.tmpl?
_xCons             37  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pCons             97  c:\cm3\pkg\parserlib\src\parser.tmpl?
_pConsUn           99  c:\cm3\pkg\parserlib\src\parser.tmpl?
parser            101  c:\cm3\pkg\parserlib\src\parser.tmpl?
include_dir         6  C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile?
                    5  C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args?
?
Fatal Error: package build failed?
 *** execution of [<function _BuildGlobalFunction at 0x0000000003280F28>, <function _ShipFunction at 0x0000000003280F98>] failed ***?
?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190531/0f3c3bc6/attachment-0001.html>