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: References: , Message-ID: Uncertain. Try other 32bit platforms. - Jay ________________________________ From: Mika Nystrom 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 > 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 ________________________________ 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 -- ? _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 > on behalf of Jay K > 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 -- ? _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 [, ] failed ***? ? - Jay _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <, LNXP123MB2089DD1AF40139C91C8215E0DD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM> <, LNXP123MB20897712A1C314F5AD1F6F1ADD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM> <, BN8PR03MB478603E1BD525BBBF6D98371E61A0@BN8PR03MB4786.namprd03.prod.outlook.com> Message-ID: 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... 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 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 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 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 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 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: 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: References: <, LNXP123MB2089DD1AF40139C91C8215E0DD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM> <, LNXP123MB20897712A1C314F5AD1F6F1ADD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM> <, BN8PR03MB478603E1BD525BBBF6D98371E61A0@BN8PR03MB4786.namprd03.prod.outlook.com> Message-ID: <5472591559403054@myt5-9da6df248f4a.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: 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: <, LNXP123MB2089DD1AF40139C91C8215E0DD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM> <, LNXP123MB20897712A1C314F5AD1F6F1ADD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM> <, BN8PR03MB478603E1BD525BBBF6D98371E61A0@BN8PR03MB4786.namprd03.prod.outlook.com> , <5472591559403054@myt5-9da6df248f4a.qloud-c.yandex.net> Message-ID: 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 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" : 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... 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 > wrote: https://github.com/modula3/cm3/commit/ce4a2b5d2fa352ddac21eb? 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 > 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 > 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 > 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? On 31/05/2019 11:57:22, Jay K > 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 https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <, LNXP123MB2089DD1AF40139C91C8215E0DD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM> <, LNXP123MB20897712A1C314F5AD1F6F1ADD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM> <, BN8PR03MB478603E1BD525BBBF6D98371E61A0@BN8PR03MB4786.namprd03.prod.outlook.com> , <5472591559403054@myt5-9da6df248f4a.qloud-c.yandex.net> Message-ID: <15751231559455923@myt2-66bcb87429e6.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: 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: References: <, LNXP123MB2089DD1AF40139C91C8215E0DD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM> <, LNXP123MB20897712A1C314F5AD1F6F1ADD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM> <, BN8PR03MB478603E1BD525BBBF6D98371E61A0@BN8PR03MB4786.namprd03.prod.outlook.com> <,5472591559403054@myt5-9da6df248f4a.qloud-c.yandex.net> Message-ID: 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 -- m3_link 1234 C:\Users\Public\programs\cm3\bin\config\NT.common program -- 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 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 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" : 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... 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 > wrote: https://github.com/modula3/cm3/commit/ce4a2b5d2fa352ddac21eb? 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 > 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 > 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 > 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? On 31/05/2019 11:57:22, Jay K > 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 https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <, LNXP123MB2089DD1AF40139C91C8215E0DD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM> <, LNXP123MB20897712A1C314F5AD1F6F1ADD190@LNXP123MB2089.GBRP123.PROD.OUTLOOK.COM> <, BN8PR03MB478603E1BD525BBBF6D98371E61A0@BN8PR03MB4786.namprd03.prod.outlook.com> <,5472591559403054@myt5-9da6df248f4a.qloud-c.yandex.net> , Message-ID: > 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 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 -- m3_link 1234 C:\Users\Public\programs\cm3\bin\config\NT.common program -- 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 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 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" : 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... 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 > wrote: https://github.com/modula3/cm3/commit/ce4a2b5d2fa352ddac21eb? 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 > 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 > 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 > 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? On 31/05/2019 11:57:22, Jay K > 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 https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: 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 On Behalf Of Jay K Sent: Monday, May 27, 2019 4:11 AM To: m3devel 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: 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: 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: 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: References: Message-ID: <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: 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: , <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net> Message-ID: 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 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" : 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 https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net> 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 on behalf of Jay K Date: Wednesday, June 5, 2019 at 7:21 PM To: "vvm at tut.by" , "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 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" : 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 https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: , <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net> Message-ID: <16217911559728605@sas2-80cfc068821c.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: 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: <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net> , <3EF74FA1-7FA7-4A52-A3CE-495FB20EEFFA@anu.edu.au> Message-ID: 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 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 on behalf of Jay K Date: Wednesday, June 5, 2019 at 7:21 PM To: "vvm at tut.by" , "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 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" : 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 https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net> <3EF74FA1-7FA7-4A52-A3CE-495FB20EEFFA@anu.edu.au> Message-ID: 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 Date: Wednesday, June 5, 2019 at 11:43 PM To: Antony Hosking , "vvm at tut.by" , "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 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 on behalf of Jay K Date: Wednesday, June 5, 2019 at 7:21 PM To: "vvm at tut.by" , "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 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" : 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 https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <16320201559725393@iva7-634c9cb1f49d.qloud-c.yandex.net> <3EF74FA1-7FA7-4A52-A3CE-495FB20EEFFA@anu.edu.au> , Message-ID: 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 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 Date: Wednesday, June 5, 2019 at 11:43 PM To: Antony Hosking , "vvm at tut.by" , "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 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 on behalf of Jay K Date: Wednesday, June 5, 2019 at 7:21 PM To: "vvm at tut.by" , "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 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" : 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 https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: 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: 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: References: Message-ID: 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 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: 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: References: 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 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: <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: <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop>, <11744581560236328@iva1-44bdf084ee9e.qloud-c.yandex.net> Message-ID: 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 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: 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: References: <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop> <11744581560236328@iva1-44bdf084ee9e.qloud-c.yandex.net> 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 > 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 > > *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 > -- 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: References: <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop> <11744581560236328@iva1-44bdf084ee9e.qloud-c.yandex.net> Message-ID: 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 > 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 > > *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 > -- 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: <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop> <11744581560236328@iva1-44bdf084ee9e.qloud-c.yandex.net> , <9f5114bd-6dac-0a03-c38d-7bb26ce4252a@lcwb.coop> Message-ID: 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 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 > 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 > > *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 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <0842dc0c-fdeb-54d6-c4b5-ba668deb4ce5@lcwb.coop> <11744581560236328@iva1-44bdf084ee9e.qloud-c.yandex.net> , Message-ID: 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 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 > 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 > > *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 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: