From jayk123 at hotmail.com  Sat Jun  1 06:30:58 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sat, 1 Jun 2019 04:30:58 +0000
Subject: [M3devel] calltech parser memory?
In-Reply-To: <CAE62oikt-2sQVav=VSudY+i2XZ8fnQEKeWWjGcJFPJjuT32Cww@mail.gmail.com>
References: <BN8PR03MB478676962B74A9259005DE5FE6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <BN8PR03MB478651C2CE1673BB883CAD0CE6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <BN8PR03MB4786EDF5FEBB867B65B2F347E6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <BN8PR03MB4786ADAADA07B910DC3A3EC1E6190@BN8PR03MB4786.namprd03.prod.outlook.com>,
 <CAE62oikt-2sQVav=VSudY+i2XZ8fnQEKeWWjGcJFPJjuT32Cww@mail.gmail.com>
Message-ID: <BN8PR03MB4786F455660B224C87B9FEDCE61A0@BN8PR03MB4786.namprd03.prod.outlook.com>

Uncertain. Try other 32bit platforms.

- Jay
________________________________
From: Mika Nystrom <mika.nystrom at gmail.com>
Sent: Friday, May 31, 2019 8:37:40 PM
To: Jay K
Cc: m3devel; Tony
Subject: Re: [M3devel] calltech parser memory?

Yes, you think it's just using a lot of memory?  The parser generator is quite inefficient, as I recall (I didn't write it so I don't remember exactly why, I think it's because it's LR1 instead of LALR1...?).

But the generated parsers are efficient...

     Mika

On Fri, May 31, 2019 at 10:56 AM Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:
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<mailto:m3devel-bounces at elegosoft.com>> on behalf of Jay K <jayk123 at hotmail.com<mailto: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
_______________________________________________
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/20190601/7335d788/attachment-0001.html>

From dmuysers at hotmail.com  Sat Jun  1 15:46:16 2019
From: dmuysers at hotmail.com (dirk muysers)
Date: Sat, 1 Jun 2019 13:46:16 +0000
Subject: [M3devel] cm3 -D order vs. config file?
In-Reply-To: <BN8PR03MB47868B6954EA9B5ACEB0928AE61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB47861192CE40C0FB1CA64118E6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <,
 LNXP123MB2089DD1AF40139C91C8215E0DD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <BN8PR03MB4786A4CE2D68A1499396757DE6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <,
 LNXP123MB20897712A1C314F5AD1F6F1ADD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <,
 BN8PR03MB478603E1BD525BBBF6D98371E61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <BN8PR03MB47868B6954EA9B5ACEB0928AE61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <LNXP123MB208921B0FF51319641B03C6EDD1A0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>

I have installed the MS Build tools, including Windows Kits.
I read:
...The required environment variables are specific to your installation and to the build architecture you choose, and might be changed by product updates or upgrades. Therefore, we strongly recommend that you use one of the installed command prompt shortcuts or command files instead of setting the environment variables in Windows yourself. For more information, see Set the Path and Environment Variables for Command-Line Builds<https://docs.microsoft.com/en-us/cpp/build/setting-the-path-and-environment-variables-for-command-line-builds?view=vs-2019>...

When I click on Visual Studio 2019>Visual Studio Tools>Developer Command Prompts, in order to inspect the required
environment settings, I get:
"Windows is searching for %comspec%. To locate the file yourself, click Browse", and after one minute, it dies,
Meanwhile when I check "set" I get:  COMSPEC=C:\Windows\system32\cmd.exe

I then try Visual Studio Installer => Repair
It downloads more than 300 MB and begins "installing package 1 of 96" etc
After more than half an hour, it asks to restart the system, because of their f...g registry.
Other huge softwares, including OSs manage to update in seconds without restarting.
But this being Microsoft, the worst company in the world,...

Well after yet another 5 minutes, having done the whole tapdance: Result, the same.
Enough is enough.
Had the M3 team completed their compiler by writing their own linker as the Oberon people did, it would have saved them  --and us users-- thousands of hours of twiddling, quaking and configuring...
I just will wait for an upcoming NT386 amd64/x86 release.
Sorry for my fit of temper.

On 01/06/2019 06:41:11, Jay K <jayk123 at hotmail.com> wrote:

https://github.com/modula3/cm3/commit/ce4a2b5d2fa352ddac21ebbc4306e587650ef35f

Works?

- Jay
________________________________
From: Jay K
Sent: Friday, May 31, 2019 9:38:42 PM
To: dirk muysers
Subject: Re: [M3devel] cm3 -D order vs. config file?

Please, maybe what will be most constructive, open github issue and be detailed? Steps & error messages?

- Jay
________________________________
From: dirk muysers <dmuysers at hotmail.com>
Sent: Friday, May 31, 2019 12:55:39 PM
To: Jay K
Subject: Re: [M3devel] cm3 -D order vs. config file?

The relevance is that the last windows release of the M3 compiler doesn't work with the MS BuildTool 2019 and its associated Windows Kits, so I am not able to compile anymore my M3 code base to x86
excutables on my Win 7 Pro amd64 box. And without a working cm3, I can't even try to adapt its source it to the new configuration.
Visual Studio & Co also has become a more and more unwieldy labyrinth like everything Microsoft.
Unfortunately we cannot do without it, because Windows runs 80% of the world's personal computers, OS X 12% and Linux only 1.5 %. So if you want to produce applications, you better do it for Windows.


On 31/05/2019 20:11:03, Jay K <jayk123 at hotmail.com> wrote:

What is the relevance?

Yes, this was done. There were problems. This should help a lot.
Better than to be unmaintained and stagnant?

 - Jay

________________________________
From: dirk muysers <dmuysers at hotmail.com>
Sent: Friday, May 31, 2019 10:32 AM
To: Jay K
Subject: Re: [M3devel] cm3 -D order vs. config file?

At Microsoft they changed ("refactored", so they say) nearly everything lately.
see https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/

On 31/05/2019 11:57:22, Jay K <jayk123 at hotmail.com> wrote:

%
% 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/20190601/c957e8ab/attachment.html>

From vvm at tut.by  Sat Jun  1 17:30:54 2019
From: vvm at tut.by (vvm at tut.by)
Date: Sat, 01 Jun 2019 18:30:54 +0300
Subject: [M3devel] cm3 -D order vs. config file?
In-Reply-To: <LNXP123MB208921B0FF51319641B03C6EDD1A0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
References: <BN8PR03MB47861192CE40C0FB1CA64118E6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <,
 LNXP123MB2089DD1AF40139C91C8215E0DD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <BN8PR03MB4786A4CE2D68A1499396757DE6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <,
 LNXP123MB20897712A1C314F5AD1F6F1ADD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <,
 BN8PR03MB478603E1BD525BBBF6D98371E61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <BN8PR03MB47868B6954EA9B5ACEB0928AE61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <LNXP123MB208921B0FF51319641B03C6EDD1A0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <5472591559403054@myt5-9da6df248f4a.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190601/5013b326/attachment-0001.html>

From jayk123 at hotmail.com  Sat Jun  1 21:29:14 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sat, 1 Jun 2019 19:29:14 +0000
Subject: [M3devel] cm3 -D order vs. config file?
In-Reply-To: <5472591559403054@myt5-9da6df248f4a.qloud-c.yandex.net>
References: <BN8PR03MB47861192CE40C0FB1CA64118E6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <,
 LNXP123MB2089DD1AF40139C91C8215E0DD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <BN8PR03MB4786A4CE2D68A1499396757DE6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <,
 LNXP123MB20897712A1C314F5AD1F6F1ADD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <,
 BN8PR03MB478603E1BD525BBBF6D98371E61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <BN8PR03MB47868B6954EA9B5ACEB0928AE61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <LNXP123MB208921B0FF51319641B03C6EDD1A0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>,
 <5472591559403054@myt5-9da6df248f4a.qloud-c.yandex.net>
Message-ID: <BN8PR03MB47867057E9CD09F82286F915E61A0@BN8PR03MB4786.namprd03.prod.outlook.com>

I don?t understand what is the problem?
Why not use the start menu ?shortcuts??

I need to add something to pick x86 vs. amd64?

I might take a crack at a cminstall update.

- Jay

- Jay
________________________________
From: vvm at tut.by <vvm at tut.by>
Sent: Saturday, June 1, 2019 8:30:54 AM
To: dirk muysers; Jay K; M3devel at elegosoft.com
Subject: Re: [M3devel] cm3 -D order vs. config file?

Hi!



> I just will wait for an upcoming NT386 amd64/x86 release.

   Why You don't want use instructions from  issue #47 ?

Today we should use ( as basis ) Visual Studio 2012 , but the "happy end" is most important?

(

I have both  64bit and 32bit Modula-3 for Windows.

But I don't have info about preferred way to upload this binary files.

)

Best regards, Victor Miasnikov


01.06.2019, 16:46, "dirk muysers" <dmuysers at hotmail.com>:
I have installed the MS Build tools, including Windows Kits.
I read:
...The required environment variables are specific to your installation and to the build architecture you choose, and might be changed by product updates or upgrades. Therefore, we strongly recommend that you use one of the installed command prompt shortcuts or command files instead of setting the environment variables in Windows yourself. For more information, see Set the Path and Environment Variables for Command-Line Builds<https://docs.microsoft.com/en-us/cpp/build/setting-the-path-and-environment-variables-for-command-line-builds?view=vs-2019>...

When I click on Visual Studio 2019>Visual Studio Tools>Developer Command Prompts, in order to inspect the required
environment settings, I get:
"Windows is searching for %comspec%. To locate the file yourself, click Browse", and after one minute, it dies,
Meanwhile when I check "set" I get:  COMSPEC=C:\Windows\system32\cmd.exe

I then try Visual Studio Installer => Repair
It downloads more than 300 MB and begins "installing package 1 of 96" etc
After more than half an hour, it asks to restart the system, because of their f...g registry.
Other huge softwares, including OSs manage to update in seconds without restarting.
But this being Microsoft, the worst company in the world,...

Well after yet another 5 minutes, having done the whole tapdance: Result, the same.
Enough is enough.
Had the M3 team completed their compiler by writing their own linker as the Oberon people did, it would have saved them  --and us users-- thousands of hours of twiddling, quaking and configuring...
I just will wait for an upcoming NT386 amd64/x86 release.
Sorry for my fit of temper.

On 01/06/2019 06:41:11, Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:

https://github.com/modula3/cm3/commit/ce4a2b5d2fa352ddac21eb?<https://github.com/modula3/cm3/commit/ce4a2b5d2fa352ddac21ebbc4306e587650ef35f>

Works?

- Jay
________________________________
From: Jay K
Sent: Friday, May 31, 2019 9:38:42 PM
To: dirk muysers
Subject: Re: [M3devel] cm3 -D order vs. config file?

Please, maybe what will be most constructive, open github issue and be detailed? Steps & error messages?

- Jay
________________________________
From: dirk muysers <dmuysers at hotmail.com<mailto:dmuysers at hotmail.com>>
Sent: Friday, May 31, 2019 12:55:39 PM
To: Jay K
Subject: Re: [M3devel] cm3 -D order vs. config file?

The relevance is that the last windows release of the M3 compiler doesn't work with the MS BuildTool 2019 and its associated Windows Kits, so I am not able to compile anymore my M3 code base to x86
excutables on my Win 7 Pro amd64 box. And without a working cm3, I can't even try to adapt its source it to the new configuration.
Visual Studio & Co also has become a more and more unwieldy labyrinth like everything Microsoft.
Unfortunately we cannot do without it, because Windows runs 80% of the world's personal computers, OS X 12% and Linux only 1.5 %. So if you want to produce applications, you better do it for Windows.


On 31/05/2019 20:11:03, Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:

What is the relevance?

Yes, this was done. There were problems. This should help a lot.
Better than to be unmaintained and stagnant?

 - Jay

________________________________
From: dirk muysers <dmuysers at hotmail.com<mailto:dmuysers at hotmail.com>>
Sent: Friday, May 31, 2019 10:32 AM
To: Jay K
Subject: Re: [M3devel] cm3 -D order vs. config file?

At Microsoft they changed ("refactored", so they say) nearly everything lately.
see https://devblogs.microsoft.com/cppblog/introducing-the-unive?<https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/>

On 31/05/2019 11:57:22, Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:

%
% 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

_______________________________________________
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/20190601/31191d04/attachment-0001.html>

From vvm at tut.by  Sun Jun  2 08:12:03 2019
From: vvm at tut.by (vvm at tut.by)
Date: Sun, 02 Jun 2019 09:12:03 +0300
Subject: [M3devel] cm3 -D order vs. config file?
In-Reply-To: <BN8PR03MB47867057E9CD09F82286F915E61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB47861192CE40C0FB1CA64118E6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <,
 LNXP123MB2089DD1AF40139C91C8215E0DD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <BN8PR03MB4786A4CE2D68A1499396757DE6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <,
 LNXP123MB20897712A1C314F5AD1F6F1ADD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <,
 BN8PR03MB478603E1BD525BBBF6D98371E61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <BN8PR03MB47868B6954EA9B5ACEB0928AE61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <LNXP123MB208921B0FF51319641B03C6EDD1A0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>,
 <5472591559403054@myt5-9da6df248f4a.qloud-c.yandex.net>
 <BN8PR03MB47867057E9CD09F82286F915E61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <15751231559455923@myt2-66bcb87429e6.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190602/70b9e9a9/attachment.html>

From dmuysers at hotmail.com  Sun Jun  2 15:43:30 2019
From: dmuysers at hotmail.com (dirk muysers)
Date: Sun, 2 Jun 2019 13:43:30 +0000
Subject: [M3devel] cm3 -D order vs. config file?
In-Reply-To: <BN8PR03MB47867057E9CD09F82286F915E61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB47861192CE40C0FB1CA64118E6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <,
 LNXP123MB2089DD1AF40139C91C8215E0DD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <BN8PR03MB4786A4CE2D68A1499396757DE6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <,
 LNXP123MB20897712A1C314F5AD1F6F1ADD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <,
 BN8PR03MB478603E1BD525BBBF6D98371E61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <BN8PR03MB47868B6954EA9B5ACEB0928AE61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <LNXP123MB208921B0FF51319641B03C6EDD1A0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <,5472591559403054@myt5-9da6df248f4a.qloud-c.yandex.net>
 <BN8PR03MB47867057E9CD09F82286F915E61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <LNXP123MB208946D395CF2F89AE3D99D2DD1B0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>

Trying to compile a minimal program.
My compiler: cm3-min_NT386-d5.10.0-VC2015-20160102

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
C:\Users\Dirk>develop
C:\Users\Dirk>cd "c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools
\VC\Auxiliary\Build
c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Buil
d>vcvarsamd64_x86.bat
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.0
** Copyright (c) 2019 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64_x86'

c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Buil
d>
d>cd %homepath%
c:\Users\Dirk>myproject
c:\Users\Dirk>cd dropbox\projects\test\src
c:\Users\Dirk\Dropbox\projects\test\src>cm3
--- building in ..\NT386 ---
new source -> compiling Main.m3
 -> linking Hello.exe
"C:\Users\Public\programs\cm3\bin\config\NT.common", line 1234: quake runtime error:
 link failed, see c:\Users\Dirk\Dropbox\projects\test\NT386\Hello.lst for more information
--procedure--  -line-  -file---
error              --  <builtin>
m3_link          1234  C:\Users\Public\programs\cm3\bin\config\NT.common
program            --  <builtin>
include_dir         3  c:\Users\Dirk\Dropbox\projects\test\src\m3makefile
                    4  c:\Users\Dirk\Dropbox\projects\test\NT386\m3make.args
Fatal Error: procedure "m3_link" defined in "C:\Users\Public\programs\cm3\bin\cm3.cfg" failed.
----------------------- Hello.lst -------------------
Microsoft (R) Incremental Linker Version 14.21.27702.2
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:Hello.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
C:\Users\Public\programs\cm3\pkg\m3core\NT386\m3core.lib
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
LINK : warning LNK4199: /DELAYLOAD:ws2_32.dll ignored; no imports found from ws2_32.dll
LINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dll
LINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dll
LINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dll
LINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dll
LINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dll
LINK : warning LNK4199: /DELAYLOAD:rpcrt4.dll ignored; no imports found from rpcrt4.dll
LINK : warning LNK4199: /DELAYLOAD:iphlpapid.dll ignored; no imports found from iphlpapid.dll
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __seh_filter_exe referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __set_app_type referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol ___setusermatherr referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __configure_narrow_argv referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol __configure_narrow_argv
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __initialize_narrow_environment referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol __initialize_narrow_environment
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __get_initial_narrow_environment referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __initterm referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __initterm_e referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol _exit referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __exit referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __set_fmode referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol ___p___argc referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol ___p___argv referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __cexit referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol __cexit
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __c_exit referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __register_thread_local_exe_atexit_callback referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __configthreadlocale referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __set_new_mode referenced in function "void __cdecl pre_cpp_initialization(void)" (?pre_cpp_initialization@@YAXXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol ___p__commode referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(utility.obj) : error LNK2019: unresolved external symbol __seh_filter_dll referenced in function ___scrt_dllmain_exception_filter
msvcrt.lib(utility.obj) : error LNK2019: unresolved external symbol __initialize_onexit_table referenced in function ___scrt_initialize_onexit_tables
msvcrt.lib(utility.obj) : error LNK2019: unresolved external symbol __register_onexit_function referenced in function __onexit
msvcrt.lib(utility.obj) : error LNK2019: unresolved external symbol __execute_onexit_table referenced in function ___scrt_dllmain_uninitialize_c
msvcrt.lib(utility.obj) : error LNK2019: unresolved external symbol __crt_atexit referenced in function __onexit
msvcrt.lib(utility.obj) : error LNK2019: unresolved external symbol __crt_at_quick_exit referenced in function _at_quick_exit
msvcrt.lib(tncleanup.obj) : error LNK2019: unresolved external symbol ___std_type_info_destroy_list referenced in function "void __cdecl __scrt_uninitialize_type_info(void)" (?__scrt_uninitialize_type_info@@YAXXZ)
msvcrt.lib(default_precision.obj) : error LNK2019: unresolved external symbol __controlfp_s referenced in function __initialize_default_precision
msvcrt.lib(utility_desktop.obj) : error LNK2019: unresolved external symbol _terminate referenced in function ___scrt_unhandled_exception_filter at 4
msvcrt.lib(utility_desktop.obj) : error LNK2019: unresolved external symbol _memset referenced in function ___scrt_fastfail
msvcrt.lib(chandler4gs.obj) : error LNK2019: unresolved external symbol __except_handler4_common referenced in function __except_handler4
Hello.exe : fatal error LNK1120: 30 unresolved externals
-----------------------
and that's it.


On 01/06/2019 21:29:21, Jay K <jayk123 at hotmail.com> wrote:

I don?t understand what is the problem?
Why not use the start menu ?shortcuts??

I need to add something to pick x86 vs. amd64?

I might take a crack at a cminstall update.

- Jay

- Jay
________________________________
From: vvm at tut.by <vvm at tut.by>
Sent: Saturday, June 1, 2019 8:30:54 AM
To: dirk muysers; Jay K; M3devel at elegosoft.com
Subject: Re: [M3devel] cm3 -D order vs. config file?

Hi!



> I just will wait for an upcoming NT386 amd64/x86 release.

   Why You don't want use instructions from  issue #47 ?

Today we should use ( as basis ) Visual Studio 2012 , but the "happy end" is most important?

(

I have both  64bit and 32bit Modula-3 for Windows.

But I don't have info about preferred way to upload this binary files.

)

Best regards, Victor Miasnikov


01.06.2019, 16:46, "dirk muysers" <dmuysers at hotmail.com>:
I have installed the MS Build tools, including Windows Kits.
I read:
...The required environment variables are specific to your installation and to the build architecture you choose, and might be changed by product updates or upgrades. Therefore, we strongly recommend that you use one of the installed command prompt shortcuts or command files instead of setting the environment variables in Windows yourself. For more information, see Set the Path and Environment Variables for Command-Line Builds<https://docs.microsoft.com/en-us/cpp/build/setting-the-path-and-environment-variables-for-command-line-builds?view=vs-2019>...

When I click on Visual Studio 2019>Visual Studio Tools>Developer Command Prompts, in order to inspect the required
environment settings, I get:
"Windows is searching for %comspec%. To locate the file yourself, click Browse", and after one minute, it dies,
Meanwhile when I check "set" I get:  COMSPEC=C:\Windows\system32\cmd.exe

I then try Visual Studio Installer => Repair
It downloads more than 300 MB and begins "installing package 1 of 96" etc
After more than half an hour, it asks to restart the system, because of their f...g registry.
Other huge softwares, including OSs manage to update in seconds without restarting.
But this being Microsoft, the worst company in the world,...

Well after yet another 5 minutes, having done the whole tapdance: Result, the same.
Enough is enough.
Had the M3 team completed their compiler by writing their own linker as the Oberon people did, it would have saved them  --and us users-- thousands of hours of twiddling, quaking and configuring...
I just will wait for an upcoming NT386 amd64/x86 release.
Sorry for my fit of temper.

On 01/06/2019 06:41:11, Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:

https://github.com/modula3/cm3/commit/ce4a2b5d2fa352ddac21eb?<https://github.com/modula3/cm3/commit/ce4a2b5d2fa352ddac21ebbc4306e587650ef35f>

Works?

- Jay
________________________________
From: Jay K
Sent: Friday, May 31, 2019 9:38:42 PM
To: dirk muysers
Subject: Re: [M3devel] cm3 -D order vs. config file?

Please, maybe what will be most constructive, open github issue and be detailed? Steps & error messages?

- Jay
________________________________
From: dirk muysers <dmuysers at hotmail.com<mailto:dmuysers at hotmail.com>>
Sent: Friday, May 31, 2019 12:55:39 PM
To: Jay K
Subject: Re: [M3devel] cm3 -D order vs. config file?

The relevance is that the last windows release of the M3 compiler doesn't work with the MS BuildTool 2019 and its associated Windows Kits, so I am not able to compile anymore my M3 code base to x86
excutables on my Win 7 Pro amd64 box. And without a working cm3, I can't even try to adapt its source it to the new configuration.
Visual Studio & Co also has become a more and more unwieldy labyrinth like everything Microsoft.
Unfortunately we cannot do without it, because Windows runs 80% of the world's personal computers, OS X 12% and Linux only 1.5 %. So if you want to produce applications, you better do it for Windows.


On 31/05/2019 20:11:03, Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:

What is the relevance?

Yes, this was done. There were problems. This should help a lot.
Better than to be unmaintained and stagnant?

 - Jay

________________________________
From: dirk muysers <dmuysers at hotmail.com<mailto:dmuysers at hotmail.com>>
Sent: Friday, May 31, 2019 10:32 AM
To: Jay K
Subject: Re: [M3devel] cm3 -D order vs. config file?

At Microsoft they changed ("refactored", so they say) nearly everything lately.
see https://devblogs.microsoft.com/cppblog/introducing-the-unive?<https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/>

On 31/05/2019 11:57:22, Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:

%
% 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

_______________________________________________
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/20190602/844d04c2/attachment-0001.html>

From jayk123 at hotmail.com  Sun Jun  2 20:28:09 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sun, 2 Jun 2019 18:28:09 +0000
Subject: [M3devel] cm3 -D order vs. config file?
In-Reply-To: <LNXP123MB208946D395CF2F89AE3D99D2DD1B0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
References: <BN8PR03MB47861192CE40C0FB1CA64118E6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <,
 LNXP123MB2089DD1AF40139C91C8215E0DD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <BN8PR03MB4786A4CE2D68A1499396757DE6190@BN8PR03MB4786.namprd03.prod.outlook.com>
 <,
 LNXP123MB20897712A1C314F5AD1F6F1ADD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <,
 BN8PR03MB478603E1BD525BBBF6D98371E61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <BN8PR03MB47868B6954EA9B5ACEB0928AE61A0@BN8PR03MB4786.namprd03.prod.outlook.com>
 <LNXP123MB208921B0FF51319641B03C6EDD1A0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
 <,5472591559403054@myt5-9da6df248f4a.qloud-c.yandex.net>
 <BN8PR03MB47867057E9CD09F82286F915E61A0@BN8PR03MB4786.namprd03.prod.outlook.com>,
 <LNXP123MB208946D395CF2F89AE3D99D2DD1B0@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <BN8PR03MB478606E0EA10B208068508C1E61B0@BN8PR03MB4786.namprd03.prod.outlook.com>

 > msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __seh_filter_exe referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)


Set CM3_VS2015_OR_NEWER=1 in your environment.
Or VS2015_OR_NEWER = TRUE in your config.?
?
Here, I reversed the default:?
?
https://github.com/modula3/cm3/commit/8cb25e9a8b8ae5c58e0c584017e60dab6afe6a17?
?
maybe some day we autodetect it.?

And yes, this is unfortunate. Makefile compatibility was broken by the splitting up of the C runtime into multiple libs.

Maybe cminstall is more worthwhile than I previously said/thought, but maybe also needs kinda  rewrite for Windows.

 - Jay

________________________________
From: dirk muysers <dmuysers at hotmail.com>
Sent: Sunday, June 2, 2019 1:43 PM
To: Jay K
Cc: m3devel at elegosoft.com
Subject: Re: [M3devel] cm3 -D order vs. config file?

Trying to compile a minimal program.
My compiler: cm3-min_NT386-d5.10.0-VC2015-20160102

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
C:\Users\Dirk>develop
C:\Users\Dirk>cd "c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools
\VC\Auxiliary\Build
c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Buil
d>vcvarsamd64_x86.bat
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.0
** Copyright (c) 2019 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64_x86'

c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Buil
d>
d>cd %homepath%
c:\Users\Dirk>myproject
c:\Users\Dirk>cd dropbox\projects\test\src
c:\Users\Dirk\Dropbox\projects\test\src>cm3
--- building in ..\NT386 ---
new source -> compiling Main.m3
 -> linking Hello.exe
"C:\Users\Public\programs\cm3\bin\config\NT.common", line 1234: quake runtime error:
 link failed, see c:\Users\Dirk\Dropbox\projects\test\NT386\Hello.lst for more information
--procedure--  -line-  -file---
error              --  <builtin>
m3_link          1234  C:\Users\Public\programs\cm3\bin\config\NT.common
program            --  <builtin>
include_dir         3  c:\Users\Dirk\Dropbox\projects\test\src\m3makefile
                    4  c:\Users\Dirk\Dropbox\projects\test\NT386\m3make.args
Fatal Error: procedure "m3_link" defined in "C:\Users\Public\programs\cm3\bin\cm3.cfg" failed.
----------------------- Hello.lst -------------------
Microsoft (R) Incremental Linker Version 14.21.27702.2
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:Hello.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
C:\Users\Public\programs\cm3\pkg\m3core\NT386\m3core.lib
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
LINK : warning LNK4199: /DELAYLOAD:ws2_32.dll ignored; no imports found from ws2_32.dll
LINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dll
LINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dll
LINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dll
LINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dll
LINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dll
LINK : warning LNK4199: /DELAYLOAD:rpcrt4.dll ignored; no imports found from rpcrt4.dll
LINK : warning LNK4199: /DELAYLOAD:iphlpapid.dll ignored; no imports found from iphlpapid.dll
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __seh_filter_exe referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __set_app_type referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol ___setusermatherr referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __configure_narrow_argv referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol __configure_narrow_argv
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __initialize_narrow_environment referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol __initialize_narrow_environment
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __get_initial_narrow_environment referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __initterm referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __initterm_e referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol _exit referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __exit referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __set_fmode referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol ___p___argc referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol ___p___argv referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __cexit referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(utility.obj) : error LNK2001: unresolved external symbol __cexit
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __c_exit referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __register_thread_local_exe_atexit_callback referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __configthreadlocale referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol __set_new_mode referenced in function "void __cdecl pre_cpp_initialization(void)" (?pre_cpp_initialization@@YAXXZ)
msvcrt.lib(exe_main.obj) : error LNK2019: unresolved external symbol ___p__commode referenced in function "int __cdecl pre_c_initialization(void)" (?pre_c_initialization@@YAHXZ)
msvcrt.lib(utility.obj) : error LNK2019: unresolved external symbol __seh_filter_dll referenced in function ___scrt_dllmain_exception_filter
msvcrt.lib(utility.obj) : error LNK2019: unresolved external symbol __initialize_onexit_table referenced in function ___scrt_initialize_onexit_tables
msvcrt.lib(utility.obj) : error LNK2019: unresolved external symbol __register_onexit_function referenced in function __onexit
msvcrt.lib(utility.obj) : error LNK2019: unresolved external symbol __execute_onexit_table referenced in function ___scrt_dllmain_uninitialize_c
msvcrt.lib(utility.obj) : error LNK2019: unresolved external symbol __crt_atexit referenced in function __onexit
msvcrt.lib(utility.obj) : error LNK2019: unresolved external symbol __crt_at_quick_exit referenced in function _at_quick_exit
msvcrt.lib(tncleanup.obj) : error LNK2019: unresolved external symbol ___std_type_info_destroy_list referenced in function "void __cdecl __scrt_uninitialize_type_info(void)" (?__scrt_uninitialize_type_info@@YAXXZ)
msvcrt.lib(default_precision.obj) : error LNK2019: unresolved external symbol __controlfp_s referenced in function __initialize_default_precision
msvcrt.lib(utility_desktop.obj) : error LNK2019: unresolved external symbol _terminate referenced in function ___scrt_unhandled_exception_filter at 4
msvcrt.lib(utility_desktop.obj) : error LNK2019: unresolved external symbol _memset referenced in function ___scrt_fastfail
msvcrt.lib(chandler4gs.obj) : error LNK2019: unresolved external symbol __except_handler4_common referenced in function __except_handler4
Hello.exe : fatal error LNK1120: 30 unresolved externals
-----------------------
and that's it.


On 01/06/2019 21:29:21, Jay K <jayk123 at hotmail.com> wrote:

I don?t understand what is the problem?
Why not use the start menu ?shortcuts??

I need to add something to pick x86 vs. amd64?

I might take a crack at a cminstall update.

- Jay

- Jay
________________________________
From: vvm at tut.by <vvm at tut.by>
Sent: Saturday, June 1, 2019 8:30:54 AM
To: dirk muysers; Jay K; M3devel at elegosoft.com
Subject: Re: [M3devel] cm3 -D order vs. config file?

Hi!



> I just will wait for an upcoming NT386 amd64/x86 release.

   Why You don't want use instructions from  issue #47 ?

Today we should use ( as basis ) Visual Studio 2012 , but the "happy end" is most important?

(

I have both  64bit and 32bit Modula-3 for Windows.

But I don't have info about preferred way to upload this binary files.

)

Best regards, Victor Miasnikov


01.06.2019, 16:46, "dirk muysers" <dmuysers at hotmail.com>:
I have installed the MS Build tools, including Windows Kits.
I read:
...The required environment variables are specific to your installation and to the build architecture you choose, and might be changed by product updates or upgrades. Therefore, we strongly recommend that you use one of the installed command prompt shortcuts or command files instead of setting the environment variables in Windows yourself. For more information, see Set the Path and Environment Variables for Command-Line Builds<https://docs.microsoft.com/en-us/cpp/build/setting-the-path-and-environment-variables-for-command-line-builds?view=vs-2019>...

When I click on Visual Studio 2019>Visual Studio Tools>Developer Command Prompts, in order to inspect the required
environment settings, I get:
"Windows is searching for %comspec%. To locate the file yourself, click Browse", and after one minute, it dies,
Meanwhile when I check "set" I get:  COMSPEC=C:\Windows\system32\cmd.exe

I then try Visual Studio Installer => Repair
It downloads more than 300 MB and begins "installing package 1 of 96" etc
After more than half an hour, it asks to restart the system, because of their f...g registry.
Other huge softwares, including OSs manage to update in seconds without restarting.
But this being Microsoft, the worst company in the world,...

Well after yet another 5 minutes, having done the whole tapdance: Result, the same.
Enough is enough.
Had the M3 team completed their compiler by writing their own linker as the Oberon people did, it would have saved them  --and us users-- thousands of hours of twiddling, quaking and configuring...
I just will wait for an upcoming NT386 amd64/x86 release.
Sorry for my fit of temper.

On 01/06/2019 06:41:11, Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:

https://github.com/modula3/cm3/commit/ce4a2b5d2fa352ddac21eb?<https://github.com/modula3/cm3/commit/ce4a2b5d2fa352ddac21ebbc4306e587650ef35f>

Works?

- Jay
________________________________
From: Jay K
Sent: Friday, May 31, 2019 9:38:42 PM
To: dirk muysers
Subject: Re: [M3devel] cm3 -D order vs. config file?

Please, maybe what will be most constructive, open github issue and be detailed? Steps & error messages?

- Jay
________________________________
From: dirk muysers <dmuysers at hotmail.com<mailto:dmuysers at hotmail.com>>
Sent: Friday, May 31, 2019 12:55:39 PM
To: Jay K
Subject: Re: [M3devel] cm3 -D order vs. config file?

The relevance is that the last windows release of the M3 compiler doesn't work with the MS BuildTool 2019 and its associated Windows Kits, so I am not able to compile anymore my M3 code base to x86
excutables on my Win 7 Pro amd64 box. And without a working cm3, I can't even try to adapt its source it to the new configuration.
Visual Studio & Co also has become a more and more unwieldy labyrinth like everything Microsoft.
Unfortunately we cannot do without it, because Windows runs 80% of the world's personal computers, OS X 12% and Linux only 1.5 %. So if you want to produce applications, you better do it for Windows.


On 31/05/2019 20:11:03, Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:

What is the relevance?

Yes, this was done. There were problems. This should help a lot.
Better than to be unmaintained and stagnant?

 - Jay

________________________________
From: dirk muysers <dmuysers at hotmail.com<mailto:dmuysers at hotmail.com>>
Sent: Friday, May 31, 2019 10:32 AM
To: Jay K
Subject: Re: [M3devel] cm3 -D order vs. config file?

At Microsoft they changed ("refactored", so they say) nearly everything lately.
see https://devblogs.microsoft.com/cppblog/introducing-the-unive?<https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/>

On 31/05/2019 11:57:22, Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:

%
% 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

_______________________________________________
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/20190602/2bc1cd8c/attachment-0001.html>

From RColeburn at comcast.net  Mon Jun  3 00:11:11 2019
From: RColeburn at comcast.net (Randy Coleburn)
Date: Sun, 2 Jun 2019 18:11:11 -0400
Subject: [M3devel] reducing support for old..?
In-Reply-To: <BN8PR03MB4786C6B7440FD5363B943F2AE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB4786C6B7440FD5363B943F2AE61D0@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <001f01d51990$178ded60$46a9c820$@comcast.net>

Jay, I still have some 32-bit machines and even some WinXP that I don't let
connect to the internet anymore.

 

From: M3devel <m3devel-bounces at elegosoft.com> On Behalf Of Jay K
Sent: Monday, May 27, 2019 4:11 AM
To: m3devel <m3devel at elegosoft.com>
Subject: [M3devel] reducing support for old..?

 

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/20190602/8194f43f/attachment.html>

From jayk123 at hotmail.com  Wed Jun  5 07:37:35 2019
From: jayk123 at hotmail.com (Jay K)
Date: Wed, 5 Jun 2019 05:37:35 +0000
Subject: [M3devel] cooperative suspend?
Message-ID: <BN8PR03MB4786F163E8B4919603E329CAE6160@BN8PR03MB4786.namprd03.prod.outlook.com>

SupendThread = GetThreadContext on wow64 make me nervous.
?
It doesn't really work as you might expect, and may or may?
not be viable.?
?
CoreCLR uses underdocumented flags with them, but isn't just?
looking for roots. It is looking for a context it can change.?
I therefore don't want to just copy it.?
Maybe if we look closer??
?
The analogous code on PPC_DARWIN fails on x86. Obscure, I realize.?
?
Thoughts:?
 1. Ignore PPC_DARWIN? ?
 2. Find the larger truths around x86 context on wow64?  ?
 3. Deprecate anything under wow64? ?
 4. Developer a cooperative suspend model? ?
?
Let's delve into the last??
I only understand it somewhat.?
?
Cooperative suspend involves no more signals and OS-level?
thread suspension, but polling, at function entry, and in loops.?
?
This is nice as it removes a bunch of platform-dependent code?
and helps debuggability (don't have to ignore those signals).?
?
How does cooperative suspend interact with calls out to C??
And with callbacks??
?
A thread that calls out to C, has to save some state (nonvolatile?
registers and stack pointer) and mark itself some how??
?
and if there are callbacks? How does that work??
The marking nests and unnests??
?
As I understand the mainline Java implementation is cooperatively suspended.
So it must be possible/easy?

 - Jay?
?

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

From vvm at tut.by  Wed Jun  5 11:03:13 2019
From: vvm at tut.by (vvm at tut.by)
Date: Wed, 05 Jun 2019 12:03:13 +0300
Subject: [M3devel] cooperative suspend?
In-Reply-To: <BN8PR03MB4786F163E8B4919603E329CAE6160@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB4786F163E8B4919603E329CAE6160@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190605/821947a7/attachment.html>

From jayk123 at hotmail.com  Wed Jun  5 11:21:15 2019
From: jayk123 at hotmail.com (Jay K)
Date: Wed, 5 Jun 2019 09:21:15 +0000
Subject: [M3devel] cooperative suspend?
In-Reply-To: <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net>
References: <BN8PR03MB4786F163E8B4919603E329CAE6160@BN8PR03MB4786.namprd03.prod.outlook.com>,
 <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net>
Message-ID: <BN8PR03MB47863FDCFC8167C4CDAA279DE6160@BN8PR03MB4786.namprd03.prod.outlook.com>

Native systems work fine.

On wow64, threads run a mix of 32bit and 64bit code.
It isn't clear what happens if you suspend and get context while in 64bit.

AMD64_NT I think is in decent condition.
So there is an argument to just not support running on wow64.

Coop would still provide, I think, a more portable system.
Albeit larger code, with the polling.
A little less responsive, since polling wouldn't be every instruction, etc.

 - Jay

________________________________
From: vvm at tut.by <vvm at tut.by>
Sent: Wednesday, June 5, 2019 9:03 AM
To: Jay K; M3devel at elegosoft.com
Subject: Re: [M3devel] cooperative suspend?

Hi!


I think additional information needs:

1) What happened on pure 32bit Windows?
( and inside VM on Hyper-V? )

2) What happened with AMD64_NT Modula-3 ?



Best regards, Victor Miasnikov


05.06.2019, 08:38, "Jay K" <jayk123 at hotmail.com>:
SupendThread = GetThreadContext on wow64 make me nervous.
?
It doesn't really work as you might expect, and may or may?
not be viable.?
?
CoreCLR uses underdocumented flags with them, but isn't just?
looking for roots. It is looking for a context it can change.?
I therefore don't want to just copy it.?
Maybe if we look closer??
?
The analogous code on PPC_DARWIN fails on x86. Obscure, I realize.?
?
Thoughts:?
 1. Ignore PPC_DARWIN? ?
 2. Find the larger truths around x86 context on wow64?  ?
 3. Deprecate anything under wow64? ?
 4. Developer a cooperative suspend model? ?
?
Let's delve into the last??
I only understand it somewhat.?
?
Cooperative suspend involves no more signals and OS-level?
thread suspension, but polling, at function entry, and in loops.?
?
This is nice as it removes a bunch of platform-dependent code?
and helps debuggability (don't have to ignore those signals).?
?
How does cooperative suspend interact with calls out to C??
And with callbacks??
?
A thread that calls out to C, has to save some state (nonvolatile?
registers and stack pointer) and mark itself some how??
?
and if there are callbacks? How does that work??
The marking nests and unnests??
?
As I understand the mainline Java implementation is cooperatively suspended.
So it must be possible/easy?

 - Jay?
?


_______________________________________________
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/20190605/55ac0c94/attachment-0001.html>

From antony.hosking at anu.edu.au  Wed Jun  5 11:56:20 2019
From: antony.hosking at anu.edu.au (Tony Hosking)
Date: Wed, 5 Jun 2019 09:56:20 +0000
Subject: [M3devel] cooperative suspend?
In-Reply-To: <BN8PR03MB47863FDCFC8167C4CDAA279DE6160@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB4786F163E8B4919603E329CAE6160@BN8PR03MB4786.namprd03.prod.outlook.com>
 <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net>
 <BN8PR03MB47863FDCFC8167C4CDAA279DE6160@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <3EF74FA1-7FA7-4A52-A3CE-495FB20EEFFA@anu.edu.au>

Cooperative suspend is definitely the preferred option.
Ideally, we have a mechanism that allows suspension by the collector of individual threads (i.e., a handshake mechanism). Suspend and resume thus look something like the following:


SUSPEND:
for each mutator thread t
                handshake t with operation:
suspended[t] := TRUE
wait

done := FALSE
while not done
                done := TRUE
for each mutator thread t
                done := done && suspended[t]

ALL THREADS ARE NOW SUSPENDED

RESUME:
for each mutator thread t
                handshake t with operation:
suspended[t]  := FALSE


From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Jay K <jayk123 at hotmail.com>
Date: Wednesday, June 5, 2019 at 7:21 PM
To: "vvm at tut.by" <vvm at tut.by>, "M3devel at elegosoft.com" <m3devel at elegosoft.com>
Subject: Re: [M3devel] cooperative suspend?

Native systems work fine.

On wow64, threads run a mix of 32bit and 64bit code.
It isn't clear what happens if you suspend and get context while in 64bit.

AMD64_NT I think is in decent condition.
So there is an argument to just not support running on wow64.

Coop would still provide, I think, a more portable system.
Albeit larger code, with the polling.
A little less responsive, since polling wouldn't be every instruction, etc.

 - Jay

________________________________
From: vvm at tut.by <vvm at tut.by>
Sent: Wednesday, June 5, 2019 9:03 AM
To: Jay K; M3devel at elegosoft.com
Subject: Re: [M3devel] cooperative suspend?

Hi!


I think additional information needs:

1) What happened on pure 32bit Windows?
( and inside VM on Hyper-V? )

2) What happened with AMD64_NT Modula-3 ?



Best regards, Victor Miasnikov

05.06.2019, 08:38, "Jay K" <jayk123 at hotmail.com>:
SupendThread = GetThreadContext on wow64 make me nervous.
?
It doesn't really work as you might expect, and may or may?
not be viable.?
?
CoreCLR uses underdocumented flags with them, but isn't just?
looking for roots. It is looking for a context it can change.?
I therefore don't want to just copy it.?
Maybe if we look closer??
?
The analogous code on PPC_DARWIN fails on x86. Obscure, I realize.?
?
Thoughts:?
 1. Ignore PPC_DARWIN? ?
 2. Find the larger truths around x86 context on wow64?  ?
 3. Deprecate anything under wow64? ?
 4. Developer a cooperative suspend model? ?
?
Let's delve into the last??
I only understand it somewhat.?
?
Cooperative suspend involves no more signals and OS-level?
thread suspension, but polling, at function entry, and in loops.?
?
This is nice as it removes a bunch of platform-dependent code?
and helps debuggability (don't have to ignore those signals).?
?
How does cooperative suspend interact with calls out to C??
And with callbacks??
?
A thread that calls out to C, has to save some state (nonvolatile?
registers and stack pointer) and mark itself some how??
?
and if there are callbacks? How does that work??
The marking nests and unnests??
?
As I understand the mainline Java implementation is cooperatively suspended.
So it must be possible/easy?

 - Jay?
?


_______________________________________________
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/20190605/8e06cbd0/attachment-0001.html>

From vvm at tut.by  Wed Jun  5 11:56:45 2019
From: vvm at tut.by (vvm at tut.by)
Date: Wed, 05 Jun 2019 12:56:45 +0300
Subject: [M3devel] cooperative suspend?
In-Reply-To: <BN8PR03MB47863FDCFC8167C4CDAA279DE6160@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB4786F163E8B4919603E329CAE6160@BN8PR03MB4786.namprd03.prod.outlook.com>,
 <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net>
 <BN8PR03MB47863FDCFC8167C4CDAA279DE6160@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <16217911559728605@sas2-80cfc068821c.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190605/72abc676/attachment.html>

From jayk123 at hotmail.com  Wed Jun  5 15:43:32 2019
From: jayk123 at hotmail.com (Jay K)
Date: Wed, 5 Jun 2019 13:43:32 +0000
Subject: [M3devel] cooperative suspend?
In-Reply-To: <3EF74FA1-7FA7-4A52-A3CE-495FB20EEFFA@anu.edu.au>
References: <BN8PR03MB4786F163E8B4919603E329CAE6160@BN8PR03MB4786.namprd03.prod.outlook.com>
 <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net>
 <BN8PR03MB47863FDCFC8167C4CDAA279DE6160@BN8PR03MB4786.namprd03.prod.outlook.com>,
 <3EF74FA1-7FA7-4A52-A3CE-495FB20EEFFA@anu.edu.au>
Message-ID: <BN8PR03MB47860FC08C6E0793D924A1E0E6160@BN8PR03MB4786.namprd03.prod.outlook.com>

Assuming a thread can call out to a long running syscall, such as read or sleep, and that GC should not wait for that, how does it work?

 - Jay

________________________________
From: Tony Hosking <antony.hosking at anu.edu.au>
Sent: Wednesday, June 5, 2019 9:56 AM
To: Jay K; vvm at tut.by; M3devel at elegosoft.com
Subject: Re: [M3devel] cooperative suspend?


Cooperative suspend is definitely the preferred option.

Ideally, we have a mechanism that allows suspension by the collector of individual threads (i.e., a handshake mechanism). Suspend and resume thus look something like the following:





SUSPEND:

for each mutator thread t

                handshake t with operation:

suspended[t] := TRUE

wait



done := FALSE

while not done

                done := TRUE

for each mutator thread t

                done := done && suspended[t]



ALL THREADS ARE NOW SUSPENDED



RESUME:

for each mutator thread t

                handshake t with operation:

suspended[t]  := FALSE





From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Jay K <jayk123 at hotmail.com>
Date: Wednesday, June 5, 2019 at 7:21 PM
To: "vvm at tut.by" <vvm at tut.by>, "M3devel at elegosoft.com" <m3devel at elegosoft.com>
Subject: Re: [M3devel] cooperative suspend?



Native systems work fine.



On wow64, threads run a mix of 32bit and 64bit code.

It isn't clear what happens if you suspend and get context while in 64bit.



AMD64_NT I think is in decent condition.

So there is an argument to just not support running on wow64.



Coop would still provide, I think, a more portable system.

Albeit larger code, with the polling.

A little less responsive, since polling wouldn't be every instruction, etc.



 - Jay



________________________________

From: vvm at tut.by <vvm at tut.by>
Sent: Wednesday, June 5, 2019 9:03 AM
To: Jay K; M3devel at elegosoft.com
Subject: Re: [M3devel] cooperative suspend?



Hi!





I think additional information needs:



1) What happened on pure 32bit Windows?

( and inside VM on Hyper-V? )



2) What happened with AMD64_NT Modula-3 ?







Best regards, Victor Miasnikov



05.06.2019, 08:38, "Jay K" <jayk123 at hotmail.com>:

SupendThread = GetThreadContext on wow64 make me nervous.

?

It doesn't really work as you might expect, and may or may?

not be viable.?

?

CoreCLR uses underdocumented flags with them, but isn't just?

looking for roots. It is looking for a context it can change.?

I therefore don't want to just copy it.?

Maybe if we look closer??

?

The analogous code on PPC_DARWIN fails on x86. Obscure, I realize.?

?

Thoughts:?

 1. Ignore PPC_DARWIN? ?

 2. Find the larger truths around x86 context on wow64?  ?

 3. Deprecate anything under wow64? ?

 4. Developer a cooperative suspend model? ?

?

Let's delve into the last??

I only understand it somewhat.?

?

Cooperative suspend involves no more signals and OS-level?

thread suspension, but polling, at function entry, and in loops.?

?

This is nice as it removes a bunch of platform-dependent code?

and helps debuggability (don't have to ignore those signals).?

?

How does cooperative suspend interact with calls out to C??

And with callbacks??

?

A thread that calls out to C, has to save some state (nonvolatile?

registers and stack pointer) and mark itself some how??

?

and if there are callbacks? How does that work??

The marking nests and unnests??

?

As I understand the mainline Java implementation is cooperatively suspended.

So it must be possible/easy?



 - Jay?

?



_______________________________________________
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/20190605/63a35512/attachment-0001.html>

From antony.hosking at anu.edu.au  Wed Jun  5 16:49:19 2019
From: antony.hosking at anu.edu.au (Tony Hosking)
Date: Wed, 5 Jun 2019 14:49:19 +0000
Subject: [M3devel] cooperative suspend?
In-Reply-To: <BN8PR03MB47860FC08C6E0793D924A1E0E6160@BN8PR03MB4786.namprd03.prod.outlook.com>
References: <BN8PR03MB4786F163E8B4919603E329CAE6160@BN8PR03MB4786.namprd03.prod.outlook.com>
 <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net>
 <BN8PR03MB47863FDCFC8167C4CDAA279DE6160@BN8PR03MB4786.namprd03.prod.outlook.com>
 <3EF74FA1-7FA7-4A52-A3CE-495FB20EEFFA@anu.edu.au>
 <BN8PR03MB47860FC08C6E0793D924A1E0E6160@BN8PR03MB4786.namprd03.prod.outlook.com>
Message-ID: <E179A507-50C0-451D-9FC2-FEC9E2F9B5DE@anu.edu.au>

Indeed, a thread waiting on a mutex would be just one such. One option is to have the thread set a flag when it leaves managed code via an external call (e.g., for syscall, etc.). Such threads are treated as if they are already stopped. The thread can check on return from the external call whether it should park itself and wait for the wakeup handshake.

From: Jay K <jayk123 at hotmail.com>
Date: Wednesday, June 5, 2019 at 11:43 PM
To: Antony Hosking <antony.hosking at anu.edu.au>, "vvm at tut.by" <vvm at tut.by>, "M3devel at elegosoft.com" <m3devel at elegosoft.com>
Subject: Re: [M3devel] cooperative suspend?

Assuming a thread can call out to a long running syscall, such as read or sleep, and that GC should not wait for that, how does it work?

 - Jay

________________________________
From: Tony Hosking <antony.hosking at anu.edu.au>
Sent: Wednesday, June 5, 2019 9:56 AM
To: Jay K; vvm at tut.by; M3devel at elegosoft.com
Subject: Re: [M3devel] cooperative suspend?


Cooperative suspend is definitely the preferred option.

Ideally, we have a mechanism that allows suspension by the collector of individual threads (i.e., a handshake mechanism). Suspend and resume thus look something like the following:





SUSPEND:

for each mutator thread t

                handshake t with operation:

suspended[t] := TRUE

wait



done := FALSE

while not done

                done := TRUE

for each mutator thread t

                done := done && suspended[t]



ALL THREADS ARE NOW SUSPENDED



RESUME:

for each mutator thread t

                handshake t with operation:

suspended[t]  := FALSE





From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Jay K <jayk123 at hotmail.com>
Date: Wednesday, June 5, 2019 at 7:21 PM
To: "vvm at tut.by" <vvm at tut.by>, "M3devel at elegosoft.com" <m3devel at elegosoft.com>
Subject: Re: [M3devel] cooperative suspend?



Native systems work fine.



On wow64, threads run a mix of 32bit and 64bit code.

It isn't clear what happens if you suspend and get context while in 64bit.



AMD64_NT I think is in decent condition.

So there is an argument to just not support running on wow64.



Coop would still provide, I think, a more portable system.

Albeit larger code, with the polling.

A little less responsive, since polling wouldn't be every instruction, etc.



 - Jay



________________________________

From: vvm at tut.by <vvm at tut.by>
Sent: Wednesday, June 5, 2019 9:03 AM
To: Jay K; M3devel at elegosoft.com
Subject: Re: [M3devel] cooperative suspend?



Hi!





I think additional information needs:



1) What happened on pure 32bit Windows?

( and inside VM on Hyper-V? )



2) What happened with AMD64_NT Modula-3 ?







Best regards, Victor Miasnikov



05.06.2019, 08:38, "Jay K" <jayk123 at hotmail.com>:

SupendThread = GetThreadContext on wow64 make me nervous.

?

It doesn't really work as you might expect, and may or may?

not be viable.?

?

CoreCLR uses underdocumented flags with them, but isn't just?

looking for roots. It is looking for a context it can change.?

I therefore don't want to just copy it.?

Maybe if we look closer??

?

The analogous code on PPC_DARWIN fails on x86. Obscure, I realize.?

?

Thoughts:?

 1. Ignore PPC_DARWIN? ?

 2. Find the larger truths around x86 context on wow64?  ?

 3. Deprecate anything under wow64? ?

 4. Developer a cooperative suspend model? ?

?

Let's delve into the last??

I only understand it somewhat.?

?

Cooperative suspend involves no more signals and OS-level?

thread suspension, but polling, at function entry, and in loops.?

?

This is nice as it removes a bunch of platform-dependent code?

and helps debuggability (don't have to ignore those signals).?

?

How does cooperative suspend interact with calls out to C??

And with callbacks??

?

A thread that calls out to C, has to save some state (nonvolatile?

registers and stack pointer) and mark itself some how??

?

and if there are callbacks? How does that work??

The marking nests and unnests??

?

As I understand the mainline Java implementation is cooperatively suspended.

So it must be possible/easy?



 - Jay?

?



_______________________________________________
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/20190605/5992bef4/attachment-0001.html>

From jayk123 at hotmail.com  Wed Jun  5 19:03:02 2019
From: jayk123 at hotmail.com (Jay K)
Date: Wed, 5 Jun 2019 17:03:02 +0000
Subject: [M3devel] cooperative suspend?
In-Reply-To: <E179A507-50C0-451D-9FC2-FEC9E2F9B5DE@anu.edu.au>
References: <BN8PR03MB4786F163E8B4919603E329CAE6160@BN8PR03MB4786.namprd03.prod.outlook.com>
 <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net>
 <BN8PR03MB47863FDCFC8167C4CDAA279DE6160@BN8PR03MB4786.namprd03.prod.outlook.com>
 <3EF74FA1-7FA7-4A52-A3CE-495FB20EEFFA@anu.edu.au>
 <BN8PR03MB47860FC08C6E0793D924A1E0E6160@BN8PR03MB4786.namprd03.prod.outlook.com>,
 <E179A507-50C0-451D-9FC2-FEC9E2F9B5DE@anu.edu.au>
Message-ID: <BN8PR03MB4786B86093474A70151F0046E6160@BN8PR03MB4786.namprd03.prod.outlook.com>

I think this is a nest/unnest situation.
?
I could pass a Modula-3 function by pointer to the OS as a callback.?

So a thread can bounce between states at every function boundary.?
?
And so entering/exiting Mod3 code needs to tweak the value.?
?
I guess it had to poll on entry anyway.

Taking the address could return a different, wrapper function.
If nobody compares function pointers for equality -- or that could be made to understand the equivalence.
If it is worth it.

There is already a need to have a fenced read on function entry to poll,
so maybe a fenced write on entry and fenced write on exit isn't so bad.

 - Jay

________________________________
From: Tony Hosking <antony.hosking at anu.edu.au>
Sent: Wednesday, June 5, 2019 2:49 PM
To: Jay K; vvm at tut.by; M3devel at elegosoft.com
Subject: Re: [M3devel] cooperative suspend?


Indeed, a thread waiting on a mutex would be just one such. One option is to have the thread set a flag when it leaves managed code via an external call (e.g., for syscall, etc.). Such threads are treated as if they are already stopped. The thread can check on return from the external call whether it should park itself and wait for the wakeup handshake.



From: Jay K <jayk123 at hotmail.com>
Date: Wednesday, June 5, 2019 at 11:43 PM
To: Antony Hosking <antony.hosking at anu.edu.au>, "vvm at tut.by" <vvm at tut.by>, "M3devel at elegosoft.com" <m3devel at elegosoft.com>
Subject: Re: [M3devel] cooperative suspend?



Assuming a thread can call out to a long running syscall, such as read or sleep, and that GC should not wait for that, how does it work?



 - Jay



________________________________

From: Tony Hosking <antony.hosking at anu.edu.au>
Sent: Wednesday, June 5, 2019 9:56 AM
To: Jay K; vvm at tut.by; M3devel at elegosoft.com
Subject: Re: [M3devel] cooperative suspend?



Cooperative suspend is definitely the preferred option.

Ideally, we have a mechanism that allows suspension by the collector of individual threads (i.e., a handshake mechanism). Suspend and resume thus look something like the following:





SUSPEND:

for each mutator thread t

                handshake t with operation:

suspended[t] := TRUE

wait



done := FALSE

while not done

                done := TRUE

for each mutator thread t

                done := done && suspended[t]



ALL THREADS ARE NOW SUSPENDED



RESUME:

for each mutator thread t

                handshake t with operation:

suspended[t]  := FALSE





From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Jay K <jayk123 at hotmail.com>
Date: Wednesday, June 5, 2019 at 7:21 PM
To: "vvm at tut.by" <vvm at tut.by>, "M3devel at elegosoft.com" <m3devel at elegosoft.com>
Subject: Re: [M3devel] cooperative suspend?



Native systems work fine.



On wow64, threads run a mix of 32bit and 64bit code.

It isn't clear what happens if you suspend and get context while in 64bit.



AMD64_NT I think is in decent condition.

So there is an argument to just not support running on wow64.



Coop would still provide, I think, a more portable system.

Albeit larger code, with the polling.

A little less responsive, since polling wouldn't be every instruction, etc.



 - Jay



________________________________

From: vvm at tut.by <vvm at tut.by>
Sent: Wednesday, June 5, 2019 9:03 AM
To: Jay K; M3devel at elegosoft.com
Subject: Re: [M3devel] cooperative suspend?



Hi!





I think additional information needs:



1) What happened on pure 32bit Windows?

( and inside VM on Hyper-V? )



2) What happened with AMD64_NT Modula-3 ?







Best regards, Victor Miasnikov



05.06.2019, 08:38, "Jay K" <jayk123 at hotmail.com>:

SupendThread = GetThreadContext on wow64 make me nervous.

?

It doesn't really work as you might expect, and may or may?

not be viable.?

?

CoreCLR uses underdocumented flags with them, but isn't just?

looking for roots. It is looking for a context it can change.?

I therefore don't want to just copy it.?

Maybe if we look closer??

?

The analogous code on PPC_DARWIN fails on x86. Obscure, I realize.?

?

Thoughts:?

 1. Ignore PPC_DARWIN? ?

 2. Find the larger truths around x86 context on wow64?  ?

 3. Deprecate anything under wow64? ?

 4. Developer a cooperative suspend model? ?

?

Let's delve into the last??

I only understand it somewhat.?

?

Cooperative suspend involves no more signals and OS-level?

thread suspension, but polling, at function entry, and in loops.?

?

This is nice as it removes a bunch of platform-dependent code?

and helps debuggability (don't have to ignore those signals).?

?

How does cooperative suspend interact with calls out to C??

And with callbacks??

?

A thread that calls out to C, has to save some state (nonvolatile?

registers and stack pointer) and mark itself some how??

?

and if there are callbacks? How does that work??

The marking nests and unnests??

?

As I understand the mainline Java implementation is cooperatively suspended.

So it must be possible/easy?



 - Jay?

?



_______________________________________________
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/20190605/9394ca93/attachment-0001.html>

From mika at alum.mit.edu  Mon Jun 10 08:57:01 2019
From: mika at alum.mit.edu (Mika Nystrom)
Date: Sun, 9 Jun 2019 23:57:01 -0700
Subject: [M3devel] Coroutines for Modula-3 released on AMD64_LINUX
Message-ID: <CAE62oik8+J3GtAivROQ5c+yCtPc0UHiVGqRfM=jdrNMSw5Oyfg@mail.gmail.com>

Hello out there in Modula-3 world,

I have today integrated into the master branch of Critical Mass Modula-3
(CM3) a library to do coroutines (cooperative multitasking).  The library
is based on getcontext/setcontext and has necessitated very minor changes
to the pthreads implementation of Modula-3 threads (these changes were
already added last year into the main line).

For information on how to use the library, consult the new interface
Coroutine.i3

https://github.com/modula3/cm3/blob/master/m3-libs/m3core/src/coroutine/Common/Coroutine.i3


This is the first of hopefully numerous releases of Intel-developed
Modula-3 software.  Intel licenses the company's contributions under a
"BSD-3-clause license", details of which are included in the distribution.

The build is for AMD64_LINUX only at the moment; on other targets, the
coroutines should be disabled (with a dummy interface so code will still
build portably, but not run).

I hope this doesn't break anything for other people (I know my importation
of various Caltech code a while back did break Windows, sorry about that).

Further code coming from Intel would not be as low-level as this, but
mainly software for various EDA-related tasks.  There are also a number of
similar libraries and programs from Caltech coming soon, as I find time to
import them.  Apologies in advance for any churn!

     Mika Nystrom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20190609/8caaceba/attachment.html>

From dmuysers at hotmail.com  Mon Jun 10 11:10:56 2019
From: dmuysers at hotmail.com (dirk muysers)
Date: Mon, 10 Jun 2019 09:10:56 +0000
Subject: [M3devel] Coroutines for Modula-3 released on AMD64_LINUX
In-Reply-To: <CAE62oik8+J3GtAivROQ5c+yCtPc0UHiVGqRfM=jdrNMSw5Oyfg@mail.gmail.com>
References: <CAE62oik8+J3GtAivROQ5c+yCtPc0UHiVGqRfM=jdrNMSw5Oyfg@mail.gmail.com>
Message-ID: <HE1PR03MB284361945520E6BCB5F64578DD130@HE1PR03MB2843.eurprd03.prod.outlook.com>

I am a very old professional programmer who was already active at the time when Unix was just born and we all did assembly only. I notice that the majority of this community mainly cares about polishing the Linux aspect of this system. This is a bit worrysome because the ultimate purpose of programming is producing applications, and applications mostly target the world of Windows. Never forget that 80% of the world's desktop computers run Windows, 12% run MacOS and Linux a poor 1.5%. Linux is for nerds, not for users. And limiting oneself to the world of Linux is like masturbating instead of producing children. I never forget that when one of us objected to John McCarthy that his solution of a given problem was not very elegant, he answered: "I leave elegance to the tailors." Modula-3 did not become mainstream because it did not care enough about Windows and producing applications for the world at large, which -- like it or not (personally i think it's one of the worst software ever produced) -- depends on Windows OSes. Sorry for that bit of  out of context Linux vs. Windows knee-jerk philosophy.

On 10/06/2019 08:57:39, Mika Nystrom <mika at alum.mit.edu> wrote:

Hello out there in Modula-3 world,

I have today integrated into the master branch of Critical Mass Modula-3 (CM3) a library to do coroutines (cooperative multitasking).  The library is based on getcontext/setcontext and has necessitated very minor changes to the pthreads implementation of Modula-3 threads (these changes were already added last year into the main line).

For information on how to use the library, consult the new interface Coroutine.i3

https://github.com/modula3/cm3/blob/master/m3-libs/m3core/src/coroutine/Common/Coroutine.i3

This is the first of hopefully numerous releases of Intel-developed Modula-3 software.  Intel licenses the company's contributions under a "BSD-3-clause license", details of which are included in the distribution.

The build is for AMD64_LINUX only at the moment; on other targets, the coroutines should be disabled (with a dummy interface so code will still build portably, but not run).

I hope this doesn't break anything for other people (I know my importation of various Caltech code a while back did break Windows, sorry about that).

Further code coming from Intel would not be as low-level as this, but mainly software for various EDA-related tasks.  There are also a number of similar libraries and programs from Caltech coming soon, as I find time to import them.  Apologies in advance for any churn!

     Mika Nystrom

_______________________________________________ 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/20190610/0b7d7f01/attachment.html>

From rodney_bates at lcwb.coop  Mon Jun 10 19:36:24 2019
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 10 Jun 2019 12:36:24 -0500
Subject: [M3devel] OT: Re: Coroutines for Modula-3 released on AMD64_LINUX
In-Reply-To: <HE1PR03MB284361945520E6BCB5F64578DD130@HE1PR03MB2843.eurprd03.prod.outlook.com>
References: <CAE62oik8+J3GtAivROQ5c+yCtPc0UHiVGqRfM=jdrNMSw5Oyfg@mail.gmail.com>
 <HE1PR03MB284361945520E6BCB5F64578DD130@HE1PR03MB2843.eurprd03.prod.outlook.com>
Message-ID: <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop>

I too am a very old professional programmer, with similarly ancient background.  I
want to put in a plug for the practical value of elegance.  Having done a lot of
maintenance work on large code bases (often hundreds of thousands of lines of code),
I consider it a clearly observable fact that inelegant code can make maintenance five
to ten times more time-consuming and error-prone than elegant code.

I have many many times found that the fastest, if not the only, way I can understand
something big and complicated well enough to enhance or fix it, with minimal introduction
of new bugs, is to first refactor it for greater elegance.  I, for one, can't fix
something if I can't thoroughly understand it, and I can't understand it, if it is
full of stuff like unstated and difficult-to-infer invariants; ambiguous, meaningless,
or misleading identifiers; inconsistencies; and all sorts of other inelegant stuff.
Yet despite my thus-limited understanding abilities, in doing it this way, I have had
better success than many of my peers.

It is no coincidence that a highly inelegant operating system is also a highly
buggy operating system.  Nor is it a coincidence that the Linux uptake numbers
are skewed quite differently in servers, where bug tolerance is dramatically
lower, than in desktops.

In small programs and textbook algorithms, elegance may be only a matter of
esthetics.  In moderate-sized and larger software systems, it has a major
positive effect on both their cost and their usefulness.

On 06/10/2019 04:10 AM, dirk muysers wrote:
> I am a very old professional programmer who was already active at the time when Unix was just born and we all did assembly only. I notice that the majority of this community mainly cares about polishing the Linux aspect of this system. This is a bit worrysome because the ultimate purpose of programming is producing applications, and applications mostly target the world of Windows. Never forget that 80% of the world's desktop computers run Windows, 12% run MacOS and Linux a poor 1.5%. Linux is for nerds, not for users. And limiting oneself to the world of Linux is like masturbating instead of producing children. I never forget that when one of us objected to John McCarthy that his solution of a given problem was not very elegant, he answered: "I leave elegance to the tailors." Modula-3 did not become mainstream because it did not care enough about Windows and producing applications for the world at large, which -- like it or not (personally i think it's one of the worst 
> software ever produced) -- depends on Windows OSes. Sorry for that bit of ?out of context Linux vs. Windows knee-jerk philosophy.
>>
>> On 10/06/2019 08:57:39, Mika Nystrom <mika at alum.mit.edu> wrote:
>>
>> Hello out there in Modula-3 world,
>>
>> I have today integrated into the master branch of Critical Mass Modula-3 (CM3) a library to do coroutines (cooperative multitasking).? The library is based on getcontext/setcontext and has necessitated very minor changes to the pthreads implementation of Modula-3 threads (these changes were already added last year into the main line).
>>
>> For information on how to use the library, consult the new interface Coroutine.i3
>>
>> https://github.com/modula3/cm3/blob/master/m3-libs/m3core/src/coroutine/Common/Coroutine.i3
>>
>> This is the first of hopefully numerous releases of Intel-developed Modula-3 software.? Intel licenses the company's contributions under a "BSD-3-clause license", details of which are included in the distribution.
>>
>> The build is for AMD64_LINUX only at the moment; on other targets, the coroutines should be disabled (with a dummy interface so code will still build portably, but not run).
>>
>> I hope this doesn't break anything for other people (I know my importation of various Caltech code a while back did break Windows, sorry about that).
>>
>> Further code coming from Intel would not be as low-level as this, but mainly software for various EDA-related tasks.? There are also a number of similar libraries and programs from Caltech coming soon, as I find time to import them.? Apologies in advance for any churn!
>>
>> ? ? ?Mika Nystrom
>> _______________________________________________ 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
> 

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

From vvm at tut.by  Tue Jun 11 08:58:48 2019
From: vvm at tut.by (vvm at tut.by)
Date: Tue, 11 Jun 2019 09:58:48 +0300
Subject: [M3devel] OT: Re: Coroutines for Modula-3 released on
 AMD64_LINUX
In-Reply-To: <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop>
References: <CAE62oik8+J3GtAivROQ5c+yCtPc0UHiVGqRfM=jdrNMSw5Oyfg@mail.gmail.com>
 <HE1PR03MB284361945520E6BCB5F64578DD130@HE1PR03MB2843.eurprd03.prod.outlook.com>
 <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop>
Message-ID: <11744581560236328@iva1-44bdf084ee9e.qloud-c.yandex.net>

Hi!


D.M.>>  I notice that the majority of this community mainly cares about polishing the Linux aspect of this system. 
D.M.>> This is a bit worrysome because the ultimate purpose of programming is producing applications, and applications mostly target the world of Windows. 
D.M.>> Never forget that 80% of the world's desktop computers run Windows, 12% run MacOS and Linux a poor 1.5%. 
D.M.>> Linux is for nerds, not for users. 

R.M.B.>  It is no coincidence that a highly inelegant operating system is also a highly buggy operating system. 
R.M.B.> Nor is it a coincidence that the Linux uptake numbersare skewed quite differently in servers, 
R.M.B.> where bug tolerance is dramatically lower, than in desktops.


 I use Windows on servers. It's elegant OS.

I always ask Linux fans one simple question: how about ReactOs ( "free Windows")?

And how about Modula-3 on OpenBSD? ( Windows use most of "security mechanisms" born in OpenBSD.)


(

  There are two minutes for humor. When some phrases has twice translated by G., we can see:

G.>  It is no coincidence that a high non-exhibitor operating system is also a high-error operating system.
G.> And it?s not by chance that Linux?s utilization indicators on servers are distorted completely differently,
G.> where error resilience is significantly lower than in desktop computers.


  This say famous G-le, nor I: 
 Linux?s utilization indicators are distorted, perverted, misrepresented, warped, mutilated, corrupt, curved, crooked, gnarled, gnarly, bowed , etc.


 May be G. have more info that we ( "common people") have?

)


 Two _facts_: since 2008 "OS VMS for x86" ( both 32bit and 64bit) isn't "high-error operating system", and it isn't "highly buggy OS"


Best regards, Victor Miasnikov


From jayk123 at hotmail.com  Tue Jun 11 10:09:56 2019
From: jayk123 at hotmail.com (Jay K)
Date: Tue, 11 Jun 2019 08:09:56 +0000
Subject: [M3devel] OT: Re: Coroutines for Modula-3 released on
 AMD64_LINUX
In-Reply-To: <11744581560236328@iva1-44bdf084ee9e.qloud-c.yandex.net>
References: <CAE62oik8+J3GtAivROQ5c+yCtPc0UHiVGqRfM=jdrNMSw5Oyfg@mail.gmail.com>
 <HE1PR03MB284361945520E6BCB5F64578DD130@HE1PR03MB2843.eurprd03.prod.outlook.com>
 <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop>,
 <11744581560236328@iva1-44bdf084ee9e.qloud-c.yandex.net>
Message-ID: <CY4PR15MB151101D02235599DC9FA052EE6ED0@CY4PR15MB1511.namprd15.prod.outlook.com>

And how to reliable write code that survives low memory on Linux?
You can't. Kernel just randomly kills processes under low memory.
And there is overcommit, so the system is allowed to get too far.
And apparently fork() all-but demands overcommit.
So the whole thing is really iffy.

Not to mention lack of exception handling in the ABI, so there is no language interop. Each language with exception handlers/finally blocks just skips the other languages.

Or the default dynamic linkage model that has a flat namespace and everything is interposable (We link Modula-3 with -Bsymbolic though).

I'm not a fan and it is unfortunate the world is going here.
I think the reason is much about quality or freedom, but simply, cheaper server OS licensing.
Perhaps the destination can be altered somewhat.
And with Microsoft's business model shifting to cloud anyway, what does it matter to Microsoft?

Anyway, for coroutines.

  1.
You could use Windows fibers. No Win32 locking mechanisms work with fibers. They depends on threadId, which gets multiplexes across fibers.
  2.
Windows 64bit also has "usermode scheduling", where you get to write your own scheduler, like you seem to want to, but Win32 locking mechanisms still work.

This pendulum seems to back and forth.
Usually "usermode threads" (but not the Windows usermode scheduling!) restrict code to running one on processor.

One kinda useful application I saw of fibers, I think, was really just an overly expensive convoluted slow emulation of C#'s "yield" (which granted, isn't fast).

 - Jay

________________________________
From: vvm at tut.by <vvm at tut.by>
Sent: Tuesday, June 11, 2019 6:58 AM
To: rodney.m.bates at acm.org; dirk muysers; Mika Nystrom; m3devel at elegosoft.com; rajit.manohar at yale.edu; Hosking Tony; Jay K
Subject: Re: [M3devel] OT: Re: Coroutines for Modula-3 released on AMD64_LINUX

Hi!


D.M.>>  I notice that the majority of this community mainly cares about polishing the Linux aspect of this system.
D.M.>> This is a bit worrysome because the ultimate purpose of programming is producing applications, and applications mostly target the world of Windows.
D.M.>> Never forget that 80% of the world's desktop computers run Windows, 12% run MacOS and Linux a poor 1.5%.
D.M.>> Linux is for nerds, not for users.

R.M.B.>  It is no coincidence that a highly inelegant operating system is also a highly buggy operating system.
R.M.B.> Nor is it a coincidence that the Linux uptake numbersare skewed quite differently in servers,
R.M.B.> where bug tolerance is dramatically lower, than in desktops.


 I use Windows on servers. It's elegant OS.

I always ask Linux fans one simple question: how about ReactOs ( "free Windows")?

And how about Modula-3 on OpenBSD? ( Windows use most of "security mechanisms" born in OpenBSD.)


(

  There are two minutes for humor. When some phrases has twice translated by G., we can see:

G.>  It is no coincidence that a high non-exhibitor operating system is also a high-error operating system.
G.> And it?s not by chance that Linux?s utilization indicators on servers are distorted completely differently,
G.> where error resilience is significantly lower than in desktop computers.


  This say famous G-le, nor I:
 Linux?s utilization indicators are distorted, perverted, misrepresented, warped, mutilated, corrupt, curved, crooked, gnarled, gnarly, bowed , etc.


 May be G. have more info that we ( "common people") have?

)


 Two _facts_: since 2008 "OS VMS for x86" ( both 32bit and 64bit) isn't "high-error operating system", and it isn't "highly buggy OS"


Best regards, Victor Miasnikov

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

From rodney_bates at lcwb.coop  Fri Jun 21 18:14:14 2019
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 21 Jun 2019 11:14:14 -0500
Subject: [M3devel] OT: Re: Coroutines for Modula-3 released on
 AMD64_LINUX
In-Reply-To: <CAE62oikxaPZjk-er2AN2Y4cnCkc7pWPSMhgb-r5=sWAFFRT3XQ@mail.gmail.com>
References: <CAE62oik8+J3GtAivROQ5c+yCtPc0UHiVGqRfM=jdrNMSw5Oyfg@mail.gmail.com>
 <HE1PR03MB284361945520E6BCB5F64578DD130@HE1PR03MB2843.eurprd03.prod.outlook.com>
 <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop>
 <11744581560236328@iva1-44bdf084ee9e.qloud-c.yandex.net>
 <CY4PR15MB151101D02235599DC9FA052EE6ED0@CY4PR15MB1511.namprd15.prod.outlook.com>
 <CAE62oikxaPZjk-er2AN2Y4cnCkc7pWPSMhgb-r5=sWAFFRT3XQ@mail.gmail.com>
Message-ID: <9f5114bd-6dac-0a03-c38d-7bb26ce4252a@lcwb.coop>



On 06/11/2019 09:33 AM, Mika Nystrom wrote:
> Hi everyone,
> 
> I'm not sure what we're discussing here.? My goal was definitely not to start a debate on Linux vs. Windows.? I uploaded an interface Coroutine.i3 together with an implementation for AMD64_LINUX simply because Intel's Engineering Computing uses that architecture exclusively in its data centers (although we call it something else).

Yes, thanks for the coroutine support.  I have been intrigued by coroutines ever since I first heard about them,
probably late 1960s and into early 1970s.  I haven't found too many places where they would be helpful, but
have always looked.

Right now, I have one very useful application, in between an incremental scanner and an incremental parser, where
each needs to maintain a lot of unrelated state across resumes of the other, and much of it is far more conveniently
and efficiently kept in the call stack, local variables, PC, etc.  I have a use-specific implementation, using
Modula3 threads, plus extra synchronization to keep them executing one at a time.  I hope to find time to look
at switching to your, undoubtedly much more general and complete, implementation.


> 
> One thing I have learned from coding almost exclusively Modula-3 for twenty years is that it encourages a style of programming is conducive to high productivity and high reliability.? The style of programming has a name, which I am pretty sure I did not invent, and it is called "interface-based programming."? In the words of the Green Book (Nelson 1991), "Programmers who have never used Modula-style interfaces tend to underestimate them." In fact, I have advised every programmer that ever worked for me to study Modula-3 simply to learn interface-based programming so that they may practice the techniques in less elegant languages (in particular, I think a good understanding of Modula-3, in particular the interface concept, is extremely helpful to writing good C code.)
> 
> In any case, what I am trying to "sell" here isn't Linux, nor is it a pthreads based implementation, or anything like that.? What I am trying to sell is simply the Coroutine interface:
> 
> INTERFACE Coroutine;
> 
> TYPE
>    T <: ROOT;
>    Closure = OBJECT METHODS
>      apply(from : T) : REFANY;
>    END;
> 
> PROCEDURE Create(cl : Closure) : T;
> PROCEDURE Call(c : T) : T;
> PROCEDURE Retval(c : T) : REFANY;
>   
> END Coroutine.
> 
> (This is complete.? The version checked into GitHub has comments that explain what the various bits do---there's really only one procedure you need to pay attention to, and that is Call, which takes as an argument the successor coroutine and returns the predecessor coroutine.? And of course, as with the method Thread.Closure.apply, Coroutine.Closure,apply contains the text of the coroutine itself.)
> 
> See
> 
> https://github.com/modula3/cm3/blob/master/m3-libs/m3core/src/coroutine/Common/Coroutine.i3
> 
> At Intel, we use coroutines as a particular interface for solving a programming problem.? The problem is building a particular class of hardware models, where components communicate in a way that closely matches coroutines (to wit, some piece of hardware is "stuttering"---i.e., repeating an operation a certain data-dependent number of times; this is very easily modeled with coroutine semantics, because every call to the coroutine that stutters goes to the same spot, which can be deeply nested on the call stack).? We did not have as a goal here to enable any sort of on-the-cheap multiprocessing or simulating concurrency without using locks, or anything like that.? It's just a semantic interface that we wanted to a very particular style of control flow.? That being said, I do *believe* that the implementation is quite good and could be used for other things too.? In any case we are contributing it to CM3 in what I hope is a non-disruptive way.
> 
> I would love to see someone provide implementations for other processor architectures or for Windows.? I don't have an opinion on the best way to do it (Windows fibers or whatnot).? Please feel free to use the AMD64_LINUX implementation (which is based on Tony's code) as a reference IF it is helpful.? I believe the dependencies of the implementation are listed to the extent that we understand them, in the coroutine implementation source files.
> 
>  ? ? ?Mika
> 
> 
> On Tue, Jun 11, 2019 at 1:10 AM Jay K <jayk123 at hotmail.com <mailto:jayk123 at hotmail.com>> wrote:
> 
>     And how to reliable write code that survives low memory on Linux?
>     You can't. Kernel just randomly kills processes under low memory.
>     And there is overcommit, so the system is allowed to get too far.
>     And apparently fork() all-but demands overcommit.
>     So the whole thing is really iffy.
> 
>     Not to mention lack of exception handling in the ABI, so there is no language interop. Each language with exception handlers/finally blocks just skips the other languages.
> 
>     Or the default dynamic linkage model that has a flat namespace and everything is interposable (We link Modula-3 with -Bsymbolic though).
> 
>     I'm not a fan and it is unfortunate the world is going here.
>     I think the reason is much about quality or freedom, but simply, cheaper server OS licensing.
>     Perhaps the destination can be altered somewhat.
>     And with Microsoft's business model shifting to cloud anyway, what does it matter to Microsoft?
> 
>     Anyway, for coroutines.
> 
>      1.
>         You could use Windows fibers. No Win32 locking mechanisms work with fibers. They depends on threadId, which gets multiplexes across fibers.
>      2.
>         Windows 64bit also has "usermode scheduling", where you get to write your own scheduler, like you seem to want to, but Win32 locking mechanisms still work.
> 
>     This pendulum seems to back and forth.
>     Usually "usermode threads" (but not the Windows usermode scheduling!) restrict code to running one on processor.
> 
>     One kinda useful application I saw of fibers, I think, was really just an overly expensive convoluted slow emulation of C#'s "yield" (which granted, isn't fast).
> 
>      ?- Jay
> 
>     ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>     *From:* vvm at tut.by <mailto:vvm at tut.by> <vvm at tut.by <mailto:vvm at tut.by>>
>     *Sent:* Tuesday, June 11, 2019 6:58 AM
>     *To:* rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org>; dirk muysers; Mika Nystrom; m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>; rajit.manohar at yale.edu <mailto:rajit.manohar at yale.edu>; Hosking Tony; Jay K
>     *Subject:* Re: [M3devel] OT: Re: Coroutines for Modula-3 released on AMD64_LINUX
>     Hi!
> 
> 
>     D.M.>>? I notice that the majority of this community mainly cares about polishing the Linux aspect of this system.
>     D.M.>> This is a bit worrysome because the ultimate purpose of programming is producing applications, and applications mostly target the world of Windows.
>     D.M.>> Never forget that 80% of the world's desktop computers run Windows, 12% run MacOS and Linux a poor 1.5%.
>     D.M.>> Linux is for nerds, not for users.
> 
>     R.M.B.>? It is no coincidence that a highly inelegant operating system is also a highly buggy operating system.
>     R.M.B.> Nor is it a coincidence that the Linux uptake numbersare skewed quite differently in servers,
>     R.M.B.> where bug tolerance is dramatically lower, than in desktops.
> 
> 
>      ?I use Windows on servers. It's elegant OS.
> 
>     I always ask Linux fans one simple question: how about ReactOs ( "free Windows")?
> 
>     And how about Modula-3 on OpenBSD? ( Windows use most of "security mechanisms" born in OpenBSD.)
> 
> 
>     (
> 
>      ? There are two minutes for humor. When some phrases has twice translated by G., we can see:
> 
>     G.>? It is no coincidence that a high non-exhibitor operating system is also a high-error operating system.
>     G.> And it?s not by chance that Linux?s utilization indicators on servers are distorted completely differently,
>     G.> where error resilience is significantly lower than in desktop computers.
> 
> 
>      ? This say famous G-le, nor I:
>      ?Linux?s utilization indicators are distorted, perverted, misrepresented, warped, mutilated, corrupt, curved, crooked, gnarled, gnarly, bowed , etc.
> 
> 
>      ?May be G. have more info that we ( "common people") have?
> 
>     )
> 
> 
>      ?Two _facts_: since 2008 "OS VMS for x86" ( both 32bit and 64bit) isn't "high-error operating system", and it isn't "highly buggy OS"
> 
> 
>     Best regards, Victor Miasnikov
> 

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

From rodney_bates at lcwb.coop  Fri Jun 21 18:37:45 2019
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 21 Jun 2019 11:37:45 -0500
Subject: [M3devel] OT: Re: Coroutines for Modula-3 released on
 AMD64_LINUX
In-Reply-To: <CAE62oikxaPZjk-er2AN2Y4cnCkc7pWPSMhgb-r5=sWAFFRT3XQ@mail.gmail.com>
References: <CAE62oik8+J3GtAivROQ5c+yCtPc0UHiVGqRfM=jdrNMSw5Oyfg@mail.gmail.com>
 <HE1PR03MB284361945520E6BCB5F64578DD130@HE1PR03MB2843.eurprd03.prod.outlook.com>
 <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop>
 <11744581560236328@iva1-44bdf084ee9e.qloud-c.yandex.net>
 <CY4PR15MB151101D02235599DC9FA052EE6ED0@CY4PR15MB1511.namprd15.prod.outlook.com>
 <CAE62oikxaPZjk-er2AN2Y4cnCkc7pWPSMhgb-r5=sWAFFRT3XQ@mail.gmail.com>
Message-ID: <edc79b8a-fc83-b4ba-d7b8-1f72372a6aad@lcwb.coop>



On 06/11/2019 09:33 AM, Mika Nystrom wrote:
> Hi everyone,
> 
> I'm not sure what we're discussing here.? My goal was definitely not to start a debate on Linux vs. Windows.? I uploaded an interface Coroutine.i3 together with an implementation for AMD64_LINUX simply because Intel's Engineering Computing uses that architecture exclusively in its data centers (although we call it something else).
> 
> One thing I have learned from coding almost exclusively Modula-3 for twenty years is that it encourages a style of programming is conducive to high productivity and high reliability.? The style of programming has a name, which I am pretty sure I did not invent, and it is called "interface-based programming."? In the words of the Green Book (Nelson 1991), "Programmers who have never used Modula-style interfaces tend to underestimate them." In fact, I have advised every programmer that ever worked for me to study Modula-3 simply to learn interface-based programming so that they may practice the techniques in less elegant languages (in particular, I think a good understanding of Modula-3, in particular the interface concept, is extremely helpful to writing good C code.)

Yes, linguistically supported interfaces and modules are an extremely valuable concept.  For a long time, I imagined
that C and C++ programmers were just using header file idioms plus makefiles to accomplish the same thing, even
with no linguistic support.  Sadly, I have found it is not so.  The distinction between what client code needs
to know to use something and what it should not know, or at least not depend on, seems completely lost on C/C++
programmers who have not used an interface-based language.  On the one hand, there are widespread instances of
implementation code in .h files.  On the other hand, many times, information that clients need is not in .h files.

I was once completely overruled, advocating for moving, or at least copying, comments giving essential preconditions
and invariants from .c file to .h file, because the standardized comment templates for header files, that the
project members had defined, had no box for them.

However, also sadly, I have seen instances where interface-orientation in a language has been entirely
subverted.  In one of my most vivid memories, I was tasked with writing some code that had to register
itself with the operating system.  This was all in Ada, an interface-oriented language.  The Register
procedure had a parameter named (I am paraphrasing) Subsystem_Name: TEXT.  So I invented what seemed
like a reasonable name for my new subsystem and passed it in.  The machine went into hard wait, with
all interrupts disabled.  Turns out, the name had to be one of a small set of strings already hard
coded deep inside the operating system.  Otherwise a runtime error occurred at a level where no
reporting of runtime errors was possible.  Moreover, the implementation code where this could be found
out was not in the procedure I called, but half a dozen or so levels deeper in a call chain.


> 
> In any case, what I am trying to "sell" here isn't Linux, nor is it a pthreads based implementation, or anything like that.? What I am trying to sell is simply the Coroutine interface:
> 
> INTERFACE Coroutine;
> 
> TYPE
>    T <: ROOT;
>    Closure = OBJECT METHODS
>      apply(from : T) : REFANY;
>    END;
> 
> PROCEDURE Create(cl : Closure) : T;
> PROCEDURE Call(c : T) : T;
> PROCEDURE Retval(c : T) : REFANY;
>   
> END Coroutine.
> 
> (This is complete.? The version checked into GitHub has comments that explain what the various bits do---there's really only one procedure you need to pay attention to, and that is Call, which takes as an argument the successor coroutine and returns the predecessor coroutine.? And of course, as with the method Thread.Closure.apply, Coroutine.Closure,apply contains the text of the coroutine itself.)
> 
> See
> 
> https://github.com/modula3/cm3/blob/master/m3-libs/m3core/src/coroutine/Common/Coroutine.i3
> 
> At Intel, we use coroutines as a particular interface for solving a programming problem.? The problem is building a particular class of hardware models, where components communicate in a way that closely matches coroutines (to wit, some piece of hardware is "stuttering"---i.e., repeating an operation a certain data-dependent number of times; this is very easily modeled with coroutine semantics, because every call to the coroutine that stutters goes to the same spot, which can be deeply nested on the call stack).? We did not have as a goal here to enable any sort of on-the-cheap multiprocessing or simulating concurrency without using locks, or anything like that.? It's just a semantic interface that we wanted to a very particular style of control flow.? That being said, I do *believe* that the implementation is quite good and could be used for other things too.? In any case we are contributing it to CM3 in what I hope is a non-disruptive way.
> 
> I would love to see someone provide implementations for other processor architectures or for Windows.? I don't have an opinion on the best way to do it (Windows fibers or whatnot).? Please feel free to use the AMD64_LINUX implementation (which is based on Tony's code) as a reference IF it is helpful.? I believe the dependencies of the implementation are listed to the extent that we understand them, in the coroutine implementation source files.
> 
>  ? ? ?Mika
> 
> 
> On Tue, Jun 11, 2019 at 1:10 AM Jay K <jayk123 at hotmail.com <mailto:jayk123 at hotmail.com>> wrote:
> 
>     And how to reliable write code that survives low memory on Linux?
>     You can't. Kernel just randomly kills processes under low memory.
>     And there is overcommit, so the system is allowed to get too far.
>     And apparently fork() all-but demands overcommit.
>     So the whole thing is really iffy.
> 
>     Not to mention lack of exception handling in the ABI, so there is no language interop. Each language with exception handlers/finally blocks just skips the other languages.
> 
>     Or the default dynamic linkage model that has a flat namespace and everything is interposable (We link Modula-3 with -Bsymbolic though).
> 
>     I'm not a fan and it is unfortunate the world is going here.
>     I think the reason is much about quality or freedom, but simply, cheaper server OS licensing.
>     Perhaps the destination can be altered somewhat.
>     And with Microsoft's business model shifting to cloud anyway, what does it matter to Microsoft?
> 
>     Anyway, for coroutines.
> 
>      1.
>         You could use Windows fibers. No Win32 locking mechanisms work with fibers. They depends on threadId, which gets multiplexes across fibers.
>      2.
>         Windows 64bit also has "usermode scheduling", where you get to write your own scheduler, like you seem to want to, but Win32 locking mechanisms still work.
> 
>     This pendulum seems to back and forth.
>     Usually "usermode threads" (but not the Windows usermode scheduling!) restrict code to running one on processor.
> 
>     One kinda useful application I saw of fibers, I think, was really just an overly expensive convoluted slow emulation of C#'s "yield" (which granted, isn't fast).
> 
>      ?- Jay
> 
>     ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>     *From:* vvm at tut.by <mailto:vvm at tut.by> <vvm at tut.by <mailto:vvm at tut.by>>
>     *Sent:* Tuesday, June 11, 2019 6:58 AM
>     *To:* rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org>; dirk muysers; Mika Nystrom; m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>; rajit.manohar at yale.edu <mailto:rajit.manohar at yale.edu>; Hosking Tony; Jay K
>     *Subject:* Re: [M3devel] OT: Re: Coroutines for Modula-3 released on AMD64_LINUX
>     Hi!
> 
> 
>     D.M.>>? I notice that the majority of this community mainly cares about polishing the Linux aspect of this system.
>     D.M.>> This is a bit worrysome because the ultimate purpose of programming is producing applications, and applications mostly target the world of Windows.
>     D.M.>> Never forget that 80% of the world's desktop computers run Windows, 12% run MacOS and Linux a poor 1.5%.
>     D.M.>> Linux is for nerds, not for users.
> 
>     R.M.B.>? It is no coincidence that a highly inelegant operating system is also a highly buggy operating system.
>     R.M.B.> Nor is it a coincidence that the Linux uptake numbersare skewed quite differently in servers,
>     R.M.B.> where bug tolerance is dramatically lower, than in desktops.
> 
> 
>      ?I use Windows on servers. It's elegant OS.
> 
>     I always ask Linux fans one simple question: how about ReactOs ( "free Windows")?
> 
>     And how about Modula-3 on OpenBSD? ( Windows use most of "security mechanisms" born in OpenBSD.)
> 
> 
>     (
> 
>      ? There are two minutes for humor. When some phrases has twice translated by G., we can see:
> 
>     G.>? It is no coincidence that a high non-exhibitor operating system is also a high-error operating system.
>     G.> And it?s not by chance that Linux?s utilization indicators on servers are distorted completely differently,
>     G.> where error resilience is significantly lower than in desktop computers.
> 
> 
>      ? This say famous G-le, nor I:
>      ?Linux?s utilization indicators are distorted, perverted, misrepresented, warped, mutilated, corrupt, curved, crooked, gnarled, gnarly, bowed , etc.
> 
> 
>      ?May be G. have more info that we ( "common people") have?
> 
>     )
> 
> 
>      ?Two _facts_: since 2008 "OS VMS for x86" ( both 32bit and 64bit) isn't "high-error operating system", and it isn't "highly buggy OS"
> 
> 
>     Best regards, Victor Miasnikov
> 

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

From jayk123 at hotmail.com  Sat Jun 22 04:43:39 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sat, 22 Jun 2019 02:43:39 +0000
Subject: [M3devel] OT: Re: Coroutines for Modula-3 released on
 AMD64_LINUX
In-Reply-To: <9f5114bd-6dac-0a03-c38d-7bb26ce4252a@lcwb.coop>
References: <CAE62oik8+J3GtAivROQ5c+yCtPc0UHiVGqRfM=jdrNMSw5Oyfg@mail.gmail.com>
 <HE1PR03MB284361945520E6BCB5F64578DD130@HE1PR03MB2843.eurprd03.prod.outlook.com>
 <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop>
 <11744581560236328@iva1-44bdf084ee9e.qloud-c.yandex.net>
 <CY4PR15MB151101D02235599DC9FA052EE6ED0@CY4PR15MB1511.namprd15.prod.outlook.com>
 <CAE62oikxaPZjk-er2AN2Y4cnCkc7pWPSMhgb-r5=sWAFFRT3XQ@mail.gmail.com>,
 <9f5114bd-6dac-0a03-c38d-7bb26ce4252a@lcwb.coop>
Message-ID: <MWHPR15MB1518973697502E0A65B27F70E6E60@MWHPR15MB1518.namprd15.prod.outlook.com>

We should look into the C# yield construct, I think. It is quite nice to program and might provide similar/same expressiveness.

- Jay
________________________________
From: Rodney M. Bates <rodney_bates at lcwb.coop>
Sent: Friday, June 21, 2019 9:14:14 AM
To: Mika Nystrom; Jay K
Cc: vvm at tut.by; rodney.m.bates at acm.org; dirk muysers; m3devel at elegosoft.com; rajit.manohar at yale.edu; Hosking Tony
Subject: Re: [M3devel] OT: Re: Coroutines for Modula-3 released on AMD64_LINUX



On 06/11/2019 09:33 AM, Mika Nystrom wrote:
> Hi everyone,
>
> I'm not sure what we're discussing here.  My goal was definitely not to start a debate on Linux vs. Windows.  I uploaded an interface Coroutine.i3 together with an implementation for AMD64_LINUX simply because Intel's Engineering Computing uses that architecture exclusively in its data centers (although we call it something else).

Yes, thanks for the coroutine support.  I have been intrigued by coroutines ever since I first heard about them,
probably late 1960s and into early 1970s.  I haven't found too many places where they would be helpful, but
have always looked.

Right now, I have one very useful application, in between an incremental scanner and an incremental parser, where
each needs to maintain a lot of unrelated state across resumes of the other, and much of it is far more conveniently
and efficiently kept in the call stack, local variables, PC, etc.  I have a use-specific implementation, using
Modula3 threads, plus extra synchronization to keep them executing one at a time.  I hope to find time to look
at switching to your, undoubtedly much more general and complete, implementation.


>
> One thing I have learned from coding almost exclusively Modula-3 for twenty years is that it encourages a style of programming is conducive to high productivity and high reliability.  The style of programming has a name, which I am pretty sure I did not invent, and it is called "interface-based programming."  In the words of the Green Book (Nelson 1991), "Programmers who have never used Modula-style interfaces tend to underestimate them." In fact, I have advised every programmer that ever worked for me to study Modula-3 simply to learn interface-based programming so that they may practice the techniques in less elegant languages (in particular, I think a good understanding of Modula-3, in particular the interface concept, is extremely helpful to writing good C code.)
>
> In any case, what I am trying to "sell" here isn't Linux, nor is it a pthreads based implementation, or anything like that.  What I am trying to sell is simply the Coroutine interface:
>
> INTERFACE Coroutine;
>
> TYPE
>    T <: ROOT;
>    Closure = OBJECT METHODS
>      apply(from : T) : REFANY;
>    END;
>
> PROCEDURE Create(cl : Closure) : T;
> PROCEDURE Call(c : T) : T;
> PROCEDURE Retval(c : T) : REFANY;
>
> END Coroutine.
>
> (This is complete.  The version checked into GitHub has comments that explain what the various bits do---there's really only one procedure you need to pay attention to, and that is Call, which takes as an argument the successor coroutine and returns the predecessor coroutine.  And of course, as with the method Thread.Closure.apply, Coroutine.Closure,apply contains the text of the coroutine itself.)
>
> See
>
> https://github.com/modula3/cm3/blob/master/m3-libs/m3core/src/coroutine/Common/Coroutine.i3
>
> At Intel, we use coroutines as a particular interface for solving a programming problem.  The problem is building a particular class of hardware models, where components communicate in a way that closely matches coroutines (to wit, some piece of hardware is "stuttering"---i.e., repeating an operation a certain data-dependent number of times; this is very easily modeled with coroutine semantics, because every call to the coroutine that stutters goes to the same spot, which can be deeply nested on the call stack).  We did not have as a goal here to enable any sort of on-the-cheap multiprocessing or simulating concurrency without using locks, or anything like that.  It's just a semantic interface that we wanted to a very particular style of control flow.  That being said, I do *believe* that the implementation is quite good and could be used for other things too.  In any case we are contributing it to CM3 in what I hope is a non-disruptive way.
>
> I would love to see someone provide implementations for other processor architectures or for Windows.  I don't have an opinion on the best way to do it (Windows fibers or whatnot).  Please feel free to use the AMD64_LINUX implementation (which is based on Tony's code) as a reference IF it is helpful.  I believe the dependencies of the implementation are listed to the extent that we understand them, in the coroutine implementation source files.
>
>       Mika
>
>
> On Tue, Jun 11, 2019 at 1:10 AM Jay K <jayk123 at hotmail.com <mailto:jayk123 at hotmail.com>> wrote:
>
>     And how to reliable write code that survives low memory on Linux?
>     You can't. Kernel just randomly kills processes under low memory.
>     And there is overcommit, so the system is allowed to get too far.
>     And apparently fork() all-but demands overcommit.
>     So the whole thing is really iffy.
>
>     Not to mention lack of exception handling in the ABI, so there is no language interop. Each language with exception handlers/finally blocks just skips the other languages.
>
>     Or the default dynamic linkage model that has a flat namespace and everything is interposable (We link Modula-3 with -Bsymbolic though).
>
>     I'm not a fan and it is unfortunate the world is going here.
>     I think the reason is much about quality or freedom, but simply, cheaper server OS licensing.
>     Perhaps the destination can be altered somewhat.
>     And with Microsoft's business model shifting to cloud anyway, what does it matter to Microsoft?
>
>     Anyway, for coroutines.
>
>      1.
>         You could use Windows fibers. No Win32 locking mechanisms work with fibers. They depends on threadId, which gets multiplexes across fibers.
>      2.
>         Windows 64bit also has "usermode scheduling", where you get to write your own scheduler, like you seem to want to, but Win32 locking mechanisms still work.
>
>     This pendulum seems to back and forth.
>     Usually "usermode threads" (but not the Windows usermode scheduling!) restrict code to running one on processor.
>
>     One kinda useful application I saw of fibers, I think, was really just an overly expensive convoluted slow emulation of C#'s "yield" (which granted, isn't fast).
>
>       - Jay
>
>     ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>     *From:* vvm at tut.by <mailto:vvm at tut.by> <vvm at tut.by <mailto:vvm at tut.by>>
>     *Sent:* Tuesday, June 11, 2019 6:58 AM
>     *To:* rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org>; dirk muysers; Mika Nystrom; m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>; rajit.manohar at yale.edu <mailto:rajit.manohar at yale.edu>; Hosking Tony; Jay K
>     *Subject:* Re: [M3devel] OT: Re: Coroutines for Modula-3 released on AMD64_LINUX
>     Hi!
>
>
>     D.M.>>  I notice that the majority of this community mainly cares about polishing the Linux aspect of this system.
>     D.M.>> This is a bit worrysome because the ultimate purpose of programming is producing applications, and applications mostly target the world of Windows.
>     D.M.>> Never forget that 80% of the world's desktop computers run Windows, 12% run MacOS and Linux a poor 1.5%.
>     D.M.>> Linux is for nerds, not for users.
>
>     R.M.B.>  It is no coincidence that a highly inelegant operating system is also a highly buggy operating system.
>     R.M.B.> Nor is it a coincidence that the Linux uptake numbersare skewed quite differently in servers,
>     R.M.B.> where bug tolerance is dramatically lower, than in desktops.
>
>
>       I use Windows on servers. It's elegant OS.
>
>     I always ask Linux fans one simple question: how about ReactOs ( "free Windows")?
>
>     And how about Modula-3 on OpenBSD? ( Windows use most of "security mechanisms" born in OpenBSD.)
>
>
>     (
>
>        There are two minutes for humor. When some phrases has twice translated by G., we can see:
>
>     G.>  It is no coincidence that a high non-exhibitor operating system is also a high-error operating system.
>     G.> And it?s not by chance that Linux?s utilization indicators on servers are distorted completely differently,
>     G.> where error resilience is significantly lower than in desktop computers.
>
>
>        This say famous G-le, nor I:
>       Linux?s utilization indicators are distorted, perverted, misrepresented, warped, mutilated, corrupt, curved, crooked, gnarled, gnarly, bowed , etc.
>
>
>       May be G. have more info that we ( "common people") have?
>
>     )
>
>
>       Two _facts_: since 2008 "OS VMS for x86" ( both 32bit and 64bit) isn't "high-error operating system", and it isn't "highly buggy OS"
>
>
>     Best regards, Victor Miasnikov
>

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

From jayk123 at hotmail.com  Sat Jun 22 04:54:36 2019
From: jayk123 at hotmail.com (Jay K)
Date: Sat, 22 Jun 2019 02:54:36 +0000
Subject: [M3devel] OT: Re: Coroutines for Modula-3 released on
 AMD64_LINUX
In-Reply-To: <edc79b8a-fc83-b4ba-d7b8-1f72372a6aad@lcwb.coop>
References: <CAE62oik8+J3GtAivROQ5c+yCtPc0UHiVGqRfM=jdrNMSw5Oyfg@mail.gmail.com>
 <HE1PR03MB284361945520E6BCB5F64578DD130@HE1PR03MB2843.eurprd03.prod.outlook.com>
 <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop>
 <11744581560236328@iva1-44bdf084ee9e.qloud-c.yandex.net>
 <CY4PR15MB151101D02235599DC9FA052EE6ED0@CY4PR15MB1511.namprd15.prod.outlook.com>
 <CAE62oikxaPZjk-er2AN2Y4cnCkc7pWPSMhgb-r5=sWAFFRT3XQ@mail.gmail.com>,
 <edc79b8a-fc83-b4ba-d7b8-1f72372a6aad@lcwb.coop>
Message-ID: <MWHPR15MB15189DF490FF0B3EA01C3724E6E60@MWHPR15MB1518.namprd15.prod.outlook.com>

Many people/systems do structure their
big C & C++ just like Modula-3 encourages.
It is the only way to sanity & everyone knows it.

However there are opposing forces.

For efficiency in the absence of LTCG/LTO, people put inline functions in .h files.

For efficiency, to avoid excess heap allocation, private fields are fairly exposed.

For I guess reasons to do with ease of use & ease of compiler implementation, but still not easy to implement, templates implementations are typically exposed. They are easier to use than Modula-3 generics ? compiler does instantiation, no build system mucking.

And, yes, no enforcement. That is maybe the problem, if there is one.

But Modula-3 also doesn?t stop you from just putting everything in one module.

- Jay
________________________________
From: Rodney M. Bates <rodney_bates at lcwb.coop>
Sent: Friday, June 21, 2019 9:37:45 AM
To: Mika Nystrom; Jay K
Cc: vvm at tut.by; rodney.m.bates at acm.org; dirk muysers; m3devel at elegosoft.com; rajit.manohar at yale.edu; Hosking Tony
Subject: Re: [M3devel] OT: Re: Coroutines for Modula-3 released on AMD64_LINUX



On 06/11/2019 09:33 AM, Mika Nystrom wrote:
> Hi everyone,
>
> I'm not sure what we're discussing here.  My goal was definitely not to start a debate on Linux vs. Windows.  I uploaded an interface Coroutine.i3 together with an implementation for AMD64_LINUX simply because Intel's Engineering Computing uses that architecture exclusively in its data centers (although we call it something else).
>
> One thing I have learned from coding almost exclusively Modula-3 for twenty years is that it encourages a style of programming is conducive to high productivity and high reliability.  The style of programming has a name, which I am pretty sure I did not invent, and it is called "interface-based programming."  In the words of the Green Book (Nelson 1991), "Programmers who have never used Modula-style interfaces tend to underestimate them." In fact, I have advised every programmer that ever worked for me to study Modula-3 simply to learn interface-based programming so that they may practice the techniques in less elegant languages (in particular, I think a good understanding of Modula-3, in particular the interface concept, is extremely helpful to writing good C code.)

Yes, linguistically supported interfaces and modules are an extremely valuable concept.  For a long time, I imagined
that C and C++ programmers were just using header file idioms plus makefiles to accomplish the same thing, even
with no linguistic support.  Sadly, I have found it is not so.  The distinction between what client code needs
to know to use something and what it should not know, or at least not depend on, seems completely lost on C/C++
programmers who have not used an interface-based language.  On the one hand, there are widespread instances of
implementation code in .h files.  On the other hand, many times, information that clients need is not in .h files.

I was once completely overruled, advocating for moving, or at least copying, comments giving essential preconditions
and invariants from .c file to .h file, because the standardized comment templates for header files, that the
project members had defined, had no box for them.

However, also sadly, I have seen instances where interface-orientation in a language has been entirely
subverted.  In one of my most vivid memories, I was tasked with writing some code that had to register
itself with the operating system.  This was all in Ada, an interface-oriented language.  The Register
procedure had a parameter named (I am paraphrasing) Subsystem_Name: TEXT.  So I invented what seemed
like a reasonable name for my new subsystem and passed it in.  The machine went into hard wait, with
all interrupts disabled.  Turns out, the name had to be one of a small set of strings already hard
coded deep inside the operating system.  Otherwise a runtime error occurred at a level where no
reporting of runtime errors was possible.  Moreover, the implementation code where this could be found
out was not in the procedure I called, but half a dozen or so levels deeper in a call chain.


>
> In any case, what I am trying to "sell" here isn't Linux, nor is it a pthreads based implementation, or anything like that.  What I am trying to sell is simply the Coroutine interface:
>
> INTERFACE Coroutine;
>
> TYPE
>    T <: ROOT;
>    Closure = OBJECT METHODS
>      apply(from : T) : REFANY;
>    END;
>
> PROCEDURE Create(cl : Closure) : T;
> PROCEDURE Call(c : T) : T;
> PROCEDURE Retval(c : T) : REFANY;
>
> END Coroutine.
>
> (This is complete.  The version checked into GitHub has comments that explain what the various bits do---there's really only one procedure you need to pay attention to, and that is Call, which takes as an argument the successor coroutine and returns the predecessor coroutine.  And of course, as with the method Thread.Closure.apply, Coroutine.Closure,apply contains the text of the coroutine itself.)
>
> See
>
> https://github.com/modula3/cm3/blob/master/m3-libs/m3core/src/coroutine/Common/Coroutine.i3
>
> At Intel, we use coroutines as a particular interface for solving a programming problem.  The problem is building a particular class of hardware models, where components communicate in a way that closely matches coroutines (to wit, some piece of hardware is "stuttering"---i.e., repeating an operation a certain data-dependent number of times; this is very easily modeled with coroutine semantics, because every call to the coroutine that stutters goes to the same spot, which can be deeply nested on the call stack).  We did not have as a goal here to enable any sort of on-the-cheap multiprocessing or simulating concurrency without using locks, or anything like that.  It's just a semantic interface that we wanted to a very particular style of control flow.  That being said, I do *believe* that the implementation is quite good and could be used for other things too.  In any case we are contributing it to CM3 in what I hope is a non-disruptive way.
>
> I would love to see someone provide implementations for other processor architectures or for Windows.  I don't have an opinion on the best way to do it (Windows fibers or whatnot).  Please feel free to use the AMD64_LINUX implementation (which is based on Tony's code) as a reference IF it is helpful.  I believe the dependencies of the implementation are listed to the extent that we understand them, in the coroutine implementation source files.
>
>       Mika
>
>
> On Tue, Jun 11, 2019 at 1:10 AM Jay K <jayk123 at hotmail.com <mailto:jayk123 at hotmail.com>> wrote:
>
>     And how to reliable write code that survives low memory on Linux?
>     You can't. Kernel just randomly kills processes under low memory.
>     And there is overcommit, so the system is allowed to get too far.
>     And apparently fork() all-but demands overcommit.
>     So the whole thing is really iffy.
>
>     Not to mention lack of exception handling in the ABI, so there is no language interop. Each language with exception handlers/finally blocks just skips the other languages.
>
>     Or the default dynamic linkage model that has a flat namespace and everything is interposable (We link Modula-3 with -Bsymbolic though).
>
>     I'm not a fan and it is unfortunate the world is going here.
>     I think the reason is much about quality or freedom, but simply, cheaper server OS licensing.
>     Perhaps the destination can be altered somewhat.
>     And with Microsoft's business model shifting to cloud anyway, what does it matter to Microsoft?
>
>     Anyway, for coroutines.
>
>      1.
>         You could use Windows fibers. No Win32 locking mechanisms work with fibers. They depends on threadId, which gets multiplexes across fibers.
>      2.
>         Windows 64bit also has "usermode scheduling", where you get to write your own scheduler, like you seem to want to, but Win32 locking mechanisms still work.
>
>     This pendulum seems to back and forth.
>     Usually "usermode threads" (but not the Windows usermode scheduling!) restrict code to running one on processor.
>
>     One kinda useful application I saw of fibers, I think, was really just an overly expensive convoluted slow emulation of C#'s "yield" (which granted, isn't fast).
>
>       - Jay
>
>     ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>     *From:* vvm at tut.by <mailto:vvm at tut.by> <vvm at tut.by <mailto:vvm at tut.by>>
>     *Sent:* Tuesday, June 11, 2019 6:58 AM
>     *To:* rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org>; dirk muysers; Mika Nystrom; m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>; rajit.manohar at yale.edu <mailto:rajit.manohar at yale.edu>; Hosking Tony; Jay K
>     *Subject:* Re: [M3devel] OT: Re: Coroutines for Modula-3 released on AMD64_LINUX
>     Hi!
>
>
>     D.M.>>  I notice that the majority of this community mainly cares about polishing the Linux aspect of this system.
>     D.M.>> This is a bit worrysome because the ultimate purpose of programming is producing applications, and applications mostly target the world of Windows.
>     D.M.>> Never forget that 80% of the world's desktop computers run Windows, 12% run MacOS and Linux a poor 1.5%.
>     D.M.>> Linux is for nerds, not for users.
>
>     R.M.B.>  It is no coincidence that a highly inelegant operating system is also a highly buggy operating system.
>     R.M.B.> Nor is it a coincidence that the Linux uptake numbersare skewed quite differently in servers,
>     R.M.B.> where bug tolerance is dramatically lower, than in desktops.
>
>
>       I use Windows on servers. It's elegant OS.
>
>     I always ask Linux fans one simple question: how about ReactOs ( "free Windows")?
>
>     And how about Modula-3 on OpenBSD? ( Windows use most of "security mechanisms" born in OpenBSD.)
>
>
>     (
>
>        There are two minutes for humor. When some phrases has twice translated by G., we can see:
>
>     G.>  It is no coincidence that a high non-exhibitor operating system is also a high-error operating system.
>     G.> And it?s not by chance that Linux?s utilization indicators on servers are distorted completely differently,
>     G.> where error resilience is significantly lower than in desktop computers.
>
>
>        This say famous G-le, nor I:
>       Linux?s utilization indicators are distorted, perverted, misrepresented, warped, mutilated, corrupt, curved, crooked, gnarled, gnarly, bowed , etc.
>
>
>       May be G. have more info that we ( "common people") have?
>
>     )
>
>
>       Two _facts_: since 2008 "OS VMS for x86" ( both 32bit and 64bit) isn't "high-error operating system", and it isn't "highly buggy OS"
>
>
>     Best regards, Victor Miasnikov
>

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