From jayk123 at hotmail.com Tue Aug 15 00:20:35 2017 From: jayk123 at hotmail.com (Jay K) Date: Mon, 14 Aug 2017 22:20:35 +0000 Subject: [M3devel] modula3 fork and virtual timer Message-ID: /mnt/d/dev2/cm3-5.8.6/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3 PROCEDURE Create_ForkExec: . . . (* Turn off the interval timer (so it won't be running in child). *) nit := Utime.struct_itimerval { it_interval := Utime.struct_timeval {0, 0}, it_value := Utime.struct_timeval {0, 0}}; IF Utime.setitimer(Utime.ITIMER_VIRTUAL, nit, oit) < 0 THEN <* ASSERT FALSE *> END; . . . fork() . . (* Enable scheduler. *) Scheduler.EnableSwitching (); (* Restore previous virtual timer. *) IF Utime.setitimer(Utime.ITIMER_VIRTUAL, oit, nit) < 0 THEN <* ASSERT FALSE *> END; This code has a number of problems. - It looks thread-unsafe -- another thread could be changing the timer. - The comments are wrong in multiple ways. The timer doesn't have to be turned off to not run in the child. Timers except alarm() are not inherited by child. It goes ahead and enables in the child anyway. Granted, after EnableSwitching, which also enables it! - Doesn't work on Microsoft's Windows Subsystem for Linux (WSL). You get back -1/EINVAL. - Is probably specific to user threads? - Fails to put a useful message in the assert other than "FALSE" Proposals: 1. Remove it. 2. Make it check for and ignore EINVAL, and possibly WSL, and not then enable in child. 3. Change it to get in parent and set in child if enabled. 4. Move it to Thread.AtFork in user threads. Though again, not clearly needed there. 5. Consider that fork+exec should work from C/C++ code in a process that is using Modula3. 6. Research posix_spawn and use it more. We can probably just use it and forget about any system that lacks it. Thoughts? WSL can be detected by searching for "Microsoft" in /proc/sys/kernel/osrelease or /proc/version. Or we can just accept -1/EINVAL here for any OS. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Tue Aug 15 03:21:15 2017 From: peter.mckinna at gmail.com (Peter McKinna) Date: Tue, 15 Aug 2017 11:21:15 +1000 Subject: [M3devel] modula3 fork and virtual timer In-Reply-To: References: Message-ID: Hi Jay, I can't see that code anywhere in that file on git. What version are you using? By the way, you wouldnt happen to know if we can get LTO support in the backend would you? Regards Peter On Tue, Aug 15, 2017 at 8:20 AM, Jay K wrote: > > /mnt/d/dev2/cm3-5.8.6/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3 > > > PROCEDURE Create_ForkExec: > > . > . > . > (* Turn off the interval timer (so it won't be running in child). *) > > nit := Utime.struct_itimerval { > it_interval := Utime.struct_timeval {0, 0}, > it_value := Utime.struct_timeval {0, 0}}; > IF Utime.setitimer(Utime.ITIMER_VIRTUAL, nit, oit) < 0 THEN > <* ASSERT FALSE *> > END; > . > . > > . > > fork() > > . > . > > > (* Enable scheduler. *) > Scheduler.EnableSwitching (); > > (* Restore previous virtual timer. *) > IF Utime.setitimer(Utime.ITIMER_VIRTUAL, oit, nit) < 0 THEN > <* ASSERT FALSE *> > END; > > > This code has a number of problems. > > - It looks thread-unsafe -- another thread could be changing the timer. > > > > - The comments are wrong in multiple ways. > The timer doesn't have to be turned off to not run in the child. > Timers except alarm() are not inherited by child. > It goes ahead and enables in the child anyway. Granted, after > EnableSwitching, > which also enables it! > > > - Doesn't work on Microsoft's Windows Subsystem for Linux (WSL). > > You get back -1/EINVAL. > > > - Is probably specific to user threads? > > > > - Fails to put a useful message in the assert other than "FALSE" > > > > Proposals: > > 1. Remove it. > 2. Make it check for and ignore EINVAL, and possibly WSL, and not then > enable in child. > 3. Change it to get in parent and set in child if enabled. > > 4. Move it to Thread.AtFork in user threads. Though again, not clearly > needed there. > > > 5. Consider that fork+exec should work from C/C++ code in a process that > is using Modula3. > > > 6. Research posix_spawn and use it more. > > We can probably just use it and forget about any system that lacks it. > > > Thoughts? > > WSL can be detected by searching for "Microsoft" in > /proc/sys/kernel/osrelease or /proc/version. > > > Or we can just accept -1/EINVAL here for any OS. > > > > - 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 Tue Aug 15 03:28:00 2017 From: jayk123 at hotmail.com (Jay K) Date: Tue, 15 Aug 2017 01:28:00 +0000 Subject: [M3devel] modula3 fork and virtual timer In-Reply-To: References: , Message-ID: Huh I'll check head later. No I probably removed LTO sorry, but C backend... Or maybe llvm? Or report latest gcc? LTO doesn't scale in compile time but Llvm has ThinLTO now.. LTO requires linker support. A matching linker? I'm not sure. - Jay ________________________________ From: Peter McKinna Sent: Monday, August 14, 2017 6:21:15 PM To: Jay K Cc: m3devel Subject: Re: [M3devel] modula3 fork and virtual timer Hi Jay, I can't see that code anywhere in that file on git. What version are you using? By the way, you wouldnt happen to know if we can get LTO support in the backend would you? Regards Peter On Tue, Aug 15, 2017 at 8:20 AM, Jay K > wrote: /mnt/d/dev2/cm3-5.8.6/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3 PROCEDURE Create_ForkExec: . . . (* Turn off the interval timer (so it won't be running in child). *) nit := Utime.struct_itimerval { it_interval := Utime.struct_timeval {0, 0}, it_value := Utime.struct_timeval {0, 0}}; IF Utime.setitimer(Utime.ITIMER_VIRTUAL, nit, oit) < 0 THEN <* ASSERT FALSE *> END; . . . fork() . . (* Enable scheduler. *) Scheduler.EnableSwitching (); (* Restore previous virtual timer. *) IF Utime.setitimer(Utime.ITIMER_VIRTUAL, oit, nit) < 0 THEN <* ASSERT FALSE *> END; This code has a number of problems. - It looks thread-unsafe -- another thread could be changing the timer. - The comments are wrong in multiple ways. The timer doesn't have to be turned off to not run in the child. Timers except alarm() are not inherited by child. It goes ahead and enables in the child anyway. Granted, after EnableSwitching, which also enables it! - Doesn't work on Microsoft's Windows Subsystem for Linux (WSL). You get back -1/EINVAL. - Is probably specific to user threads? - Fails to put a useful message in the assert other than "FALSE" Proposals: 1. Remove it. 2. Make it check for and ignore EINVAL, and possibly WSL, and not then enable in child. 3. Change it to get in parent and set in child if enabled. 4. Move it to Thread.AtFork in user threads. Though again, not clearly needed there. 5. Consider that fork+exec should work from C/C++ code in a process that is using Modula3. 6. Research posix_spawn and use it more. We can probably just use it and forget about any system that lacks it. Thoughts? WSL can be detected by searching for "Microsoft" in /proc/sys/kernel/osrelease or /proc/version. Or we can just accept -1/EINVAL here for any OS. - 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 Tue Aug 15 09:25:12 2017 From: jayk123 at hotmail.com (Jay K) Date: Tue, 15 Aug 2017 07:25:12 +0000 Subject: [M3devel] modula3 fork and virtual timer In-Reply-To: References: , , Message-ID: Ah, I removed it in 2010. Head is much better than 5.8.6 here. https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3 Revision 1.13: download - view: text, markup, annotated - select for diffs Sun Apr 11 13:01:43 2010 (7 years, 4 months ago) by jkrell Branches: MAIN Diff to: previous 1.12: preferred, unified Changes since revision 1.12: +1 -15 lines There is no need to disable the interval timer around fork. It doesn't get inherited by the child. Revision 1.14: download - view: text, markup, annotated - select for diffs Sun Apr 11 13:04:38 2010 (7 years, 4 months ago) by jkrell Branches: MAIN Diff to: previous 1.13: preferred, unified Changes since revision 1.13: +1 -7 lines There's also no need to disable/enable scheduling, ThreadPosix.m3 registers fork handlers to do that. Do you have code that LTO will really help? i.e. cross module inlining? The gcc backend imho was just too large, so I cut out stuff that didn't seem worthwhile -- gmp, mpfr, mpc, lto... I asked a while ago, I'll ask again -- port latest gcc? Or what is the state of llvm? Would it be horrible if I started from scratch there? I think I'd output the textual IR files. I'm also somewhat keen on writing a Modula-3 IR JIT or interpreter, however I fear one or two of the files (in C++ and Cpreprocessor) I'd like to start from GPL2 and stuck there. One wonders how good or bad our IR is for a JIT input -- it is backend input, sort of (gcc backend transforms it into gcc IR) - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Tuesday, August 15, 2017 1:28 AM To: Peter McKinna Cc: m3devel Subject: Re: [M3devel] modula3 fork and virtual timer Huh I'll check head later. No I probably removed LTO sorry, but C backend... Or maybe llvm? Or report latest gcc? LTO doesn't scale in compile time but Llvm has ThinLTO now.. LTO requires linker support. A matching linker? I'm not sure. - Jay ________________________________ From: Peter McKinna Sent: Monday, August 14, 2017 6:21:15 PM To: Jay K Cc: m3devel Subject: Re: [M3devel] modula3 fork and virtual timer Hi Jay, I can't see that code anywhere in that file on git. What version are you using? By the way, you wouldnt happen to know if we can get LTO support in the backend would you? Regards Peter On Tue, Aug 15, 2017 at 8:20 AM, Jay K > wrote: /mnt/d/dev2/cm3-5.8.6/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3 PROCEDURE Create_ForkExec: . . . (* Turn off the interval timer (so it won't be running in child). *) nit := Utime.struct_itimerval { it_interval := Utime.struct_timeval {0, 0}, it_value := Utime.struct_timeval {0, 0}}; IF Utime.setitimer(Utime.ITIMER_VIRTUAL, nit, oit) < 0 THEN <* ASSERT FALSE *> END; . . . fork() . . (* Enable scheduler. *) Scheduler.EnableSwitching (); (* Restore previous virtual timer. *) IF Utime.setitimer(Utime.ITIMER_VIRTUAL, oit, nit) < 0 THEN <* ASSERT FALSE *> END; This code has a number of problems. - It looks thread-unsafe -- another thread could be changing the timer. - The comments are wrong in multiple ways. The timer doesn't have to be turned off to not run in the child. Timers except alarm() are not inherited by child. It goes ahead and enables in the child anyway. Granted, after EnableSwitching, which also enables it! - Doesn't work on Microsoft's Windows Subsystem for Linux (WSL). You get back -1/EINVAL. - Is probably specific to user threads? - Fails to put a useful message in the assert other than "FALSE" Proposals: 1. Remove it. 2. Make it check for and ignore EINVAL, and possibly WSL, and not then enable in child. 3. Change it to get in parent and set in child if enabled. 4. Move it to Thread.AtFork in user threads. Though again, not clearly needed there. 5. Consider that fork+exec should work from C/C++ code in a process that is using Modula3. 6. Research posix_spawn and use it more. We can probably just use it and forget about any system that lacks it. Thoughts? WSL can be detected by searching for "Microsoft" in /proc/sys/kernel/osrelease or /proc/version. Or we can just accept -1/EINVAL here for any OS. - Jay _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Tue Aug 15 10:03:28 2017 From: peter.mckinna at gmail.com (Peter McKinna) Date: Tue, 15 Aug 2017 18:03:28 +1000 Subject: [M3devel] modula3 fork and virtual timer In-Reply-To: References: Message-ID: Well my interest in LTO was prompted in part when I converted a C module which implemented the Viola-Jones facial detection algorithm. (I'll upload it to git some day as an example) Even with threads it seemed slower. And I think the difference was that they used some AVX code on some of the inner loops. So I was thinking about the best way to get vector support. The harder way would be to add a new type to the language say VECTOR which is similar to ARRAY but with obvious restrictions that the element type would only be integer or float and the operations would correspond to the AVX ops or if you look at the LLVM vector support something like that. Anyway a lot of work on the front end and all the backends. But it would be simpler to just have an interface to the gcc compiler functions for AVX and for that you would need a C layer to do the actual calls. But to avoid the call/return to the C layer you could use LTO to do the inlining. (I think the inlining is only done at O3 so we would have to extend the simple cm3 optimisation flag to allow users to request the level they wanted) And I for one would support an upgrade to the latest gcc. I think its about version 7 now. Regards Peter On Tue, Aug 15, 2017 at 5:25 PM, Jay K wrote: > Ah, I removed it in 2010. Head is much better than 5.8.6 here. > > > https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3- > libs/libm3/src/os/POSIX/ProcessPosixCommon.m3 > > > Revision *1.13*: download > > - view: text > , > markup > , > annotated > > - select for diffs > > *Sun Apr 11 13:01:43 2010 *(7 years, 4 months ago) by *jkrell* > Branches: MAIN > > Diff to: previous 1.12: preferred > , > unified > > Changes since revision 1.12: +1 -15 lines > > There is no need to disable the interval timer around fork. > It doesn't get inherited by the child. > > > Revision *1.14*: download > > - view: text > , > markup > , > annotated > > - select for diffs > > *Sun Apr 11 13:04:38 2010 *(7 years, 4 months ago) by *jkrell* > Branches: MAIN > > Diff to: previous 1.13: preferred > , > unified > > Changes since revision 1.13: +1 -7 lines > > There's also no need to disable/enable scheduling, ThreadPosix.m3 registers fork handlers to do that. > > > Do you have code that LTO will really help? > i.e. cross module inlining? > > The gcc backend imho was just too large, so I cut out stuff that didn't > seem worthwhile -- gmp, mpfr, mpc, lto... > > I asked a while ago, I'll ask again -- port latest gcc? > Or what is the state of llvm? Would it be horrible if I started from > scratch there? > I think I'd output the textual IR files. > > I'm also somewhat keen on writing a Modula-3 IR JIT or interpreter, > however I fear one or two of the files (in C++ and Cpreprocessor) I'd like > to start from GPL2 and stuck there. > One wonders how good or bad our IR is for a JIT input -- it is backend > input, sort of (gcc backend transforms it into gcc IR) > > - Jay > > > ------------------------------ > *From:* M3devel on behalf of Jay K < > jayk123 at hotmail.com> > *Sent:* Tuesday, August 15, 2017 1:28 AM > *To:* Peter McKinna > > *Cc:* m3devel > *Subject:* Re: [M3devel] modula3 fork and virtual timer > > Huh I'll check head later. > No I probably removed LTO sorry, but C backend... > Or maybe llvm? > Or report latest gcc? > LTO doesn't scale in compile time but Llvm has ThinLTO now.. > LTO requires linker support. A matching linker? I'm not sure. > > - Jay > ------------------------------ > *From:* Peter McKinna > *Sent:* Monday, August 14, 2017 6:21:15 PM > *To:* Jay K > *Cc:* m3devel > *Subject:* Re: [M3devel] modula3 fork and virtual timer > > Hi Jay, > > I can't see that code anywhere in that file on git. What version are you > using? > > By the way, you wouldnt happen to know if we can get LTO support in the > backend would you? > > Regards Peter > > > > On Tue, Aug 15, 2017 at 8:20 AM, Jay K wrote: > >> >> /mnt/d/dev2/cm3-5.8.6/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3 >> >> >> PROCEDURE Create_ForkExec: >> >> . >> . >> . >> (* Turn off the interval timer (so it won't be running in child). *) >> >> nit := Utime.struct_itimerval { >> it_interval := Utime.struct_timeval {0, 0}, >> it_value := Utime.struct_timeval {0, 0}}; >> IF Utime.setitimer(Utime.ITIMER_VIRTUAL, nit, oit) < 0 THEN >> <* ASSERT FALSE *> >> END; >> . >> . >> >> . >> >> fork() >> >> . >> . >> >> >> (* Enable scheduler. *) >> Scheduler.EnableSwitching (); >> >> (* Restore previous virtual timer. *) >> IF Utime.setitimer(Utime.ITIMER_VIRTUAL, oit, nit) < 0 THEN >> <* ASSERT FALSE *> >> END; >> >> >> This code has a number of problems. >> >> - It looks thread-unsafe -- another thread could be changing the timer. >> >> >> >> - The comments are wrong in multiple ways. >> The timer doesn't have to be turned off to not run in the child. >> Timers except alarm() are not inherited by child. >> It goes ahead and enables in the child anyway. Granted, after >> EnableSwitching, >> which also enables it! >> >> >> - Doesn't work on Microsoft's Windows Subsystem for Linux (WSL). >> >> You get back -1/EINVAL. >> >> >> - Is probably specific to user threads? >> >> >> >> - Fails to put a useful message in the assert other than "FALSE" >> >> >> >> Proposals: >> >> 1. Remove it. >> 2. Make it check for and ignore EINVAL, and possibly WSL, and not then >> enable in child. >> 3. Change it to get in parent and set in child if enabled. >> >> 4. Move it to Thread.AtFork in user threads. Though again, not clearly >> needed there. >> >> >> 5. Consider that fork+exec should work from C/C++ code in a process that >> is using Modula3. >> >> >> 6. Research posix_spawn and use it more. >> >> We can probably just use it and forget about any system that lacks it. >> >> >> Thoughts? >> >> WSL can be detected by searching for "Microsoft" in >> /proc/sys/kernel/osrelease or /proc/version. >> >> >> Or we can just accept -1/EINVAL here for any OS. >> >> >> >> - 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 Aug 16 04:08:38 2017 From: jayk123 at hotmail.com (Jay K) Date: Wed, 16 Aug 2017 02:08:38 +0000 Subject: [M3devel] modula3 fork and virtual timer In-Reply-To: References: , Message-ID: Upgrading gcc might be a good idea. I won't remove LTO this time, but remember optimization and Modula-3 have a not great history. I did go through an exercise of enabling lots of optimizations and searching out which ones broke things, but not why or fixing them -- just changing Modula-3 to always disable them. I also found in some cases, they were removed from later gcc anyway. Note that the IR output by Modula-3 into gcc is more difficult for gcc to optimize than normal C or C++, because it is lower level. It won't be able to do type based alias analysis, and the amount of address-taken and cast is probably more than "normal" and will defeat optimization. Yes we are very far behind, like 7 years. I have an idea that AVX et. al. should be mostly implementable as libraries and not language extensions. - Jay ________________________________ From: Peter McKinna Sent: Tuesday, August 15, 2017 8:03 AM To: Jay K Cc: m3devel Subject: Re: [M3devel] modula3 fork and virtual timer Well my interest in LTO was prompted in part when I converted a C module which implemented the Viola-Jones facial detection algorithm. (I'll upload it to git some day as an example) Even with threads it seemed slower. And I think the difference was that they used some AVX code on some of the inner loops. So I was thinking about the best way to get vector support. The harder way would be to add a new type to the language say VECTOR which is similar to ARRAY but with obvious restrictions that the element type would only be integer or float and the operations would correspond to the AVX ops or if you look at the LLVM vector support something like that. Anyway a lot of work on the front end and all the backends. But it would be simpler to just have an interface to the gcc compiler functions for AVX and for that you would need a C layer to do the actual calls. But to avoid the call/return to the C layer you could use LTO to do the inlining. (I think the inlining is only done at O3 so we would have to extend the simple cm3 optimisation flag to allow users to request the level they wanted) And I for one would support an upgrade to the latest gcc. I think its about version 7 now. Regards Peter On Tue, Aug 15, 2017 at 5:25 PM, Jay K > wrote: Ah, I removed it in 2010. Head is much better than 5.8.6 here. https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3 Revision 1.13: download - view: text, markup, annotated - select for diffs Sun Apr 11 13:01:43 2010 (7 years, 4 months ago) by jkrell Branches: MAIN Diff to: previous 1.12: preferred, unified Changes since revision 1.12: +1 -15 lines There is no need to disable the interval timer around fork. It doesn't get inherited by the child. Revision 1.14: download - view: text, markup, annotated - select for diffs Sun Apr 11 13:04:38 2010 (7 years, 4 months ago) by jkrell Branches: MAIN Diff to: previous 1.13: preferred, unified Changes since revision 1.13: +1 -7 lines There's also no need to disable/enable scheduling, ThreadPosix.m3 registers fork handlers to do that. Do you have code that LTO will really help? i.e. cross module inlining? The gcc backend imho was just too large, so I cut out stuff that didn't seem worthwhile -- gmp, mpfr, mpc, lto... I asked a while ago, I'll ask again -- port latest gcc? Or what is the state of llvm? Would it be horrible if I started from scratch there? I think I'd output the textual IR files. I'm also somewhat keen on writing a Modula-3 IR JIT or interpreter, however I fear one or two of the files (in C++ and Cpreprocessor) I'd like to start from GPL2 and stuck there. One wonders how good or bad our IR is for a JIT input -- it is backend input, sort of (gcc backend transforms it into gcc IR) - Jay ________________________________ From: M3devel > on behalf of Jay K > Sent: Tuesday, August 15, 2017 1:28 AM To: Peter McKinna Cc: m3devel Subject: Re: [M3devel] modula3 fork and virtual timer Huh I'll check head later. No I probably removed LTO sorry, but C backend... Or maybe llvm? Or report latest gcc? LTO doesn't scale in compile time but Llvm has ThinLTO now.. LTO requires linker support. A matching linker? I'm not sure. - Jay ________________________________ From: Peter McKinna > Sent: Monday, August 14, 2017 6:21:15 PM To: Jay K Cc: m3devel Subject: Re: [M3devel] modula3 fork and virtual timer Hi Jay, I can't see that code anywhere in that file on git. What version are you using? By the way, you wouldnt happen to know if we can get LTO support in the backend would you? Regards Peter On Tue, Aug 15, 2017 at 8:20 AM, Jay K > wrote: /mnt/d/dev2/cm3-5.8.6/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3 PROCEDURE Create_ForkExec: . . . (* Turn off the interval timer (so it won't be running in child). *) nit := Utime.struct_itimerval { it_interval := Utime.struct_timeval {0, 0}, it_value := Utime.struct_timeval {0, 0}}; IF Utime.setitimer(Utime.ITIMER_VIRTUAL, nit, oit) < 0 THEN <* ASSERT FALSE *> END; . . . fork() . . (* Enable scheduler. *) Scheduler.EnableSwitching (); (* Restore previous virtual timer. *) IF Utime.setitimer(Utime.ITIMER_VIRTUAL, oit, nit) < 0 THEN <* ASSERT FALSE *> END; This code has a number of problems. - It looks thread-unsafe -- another thread could be changing the timer. - The comments are wrong in multiple ways. The timer doesn't have to be turned off to not run in the child. Timers except alarm() are not inherited by child. It goes ahead and enables in the child anyway. Granted, after EnableSwitching, which also enables it! - Doesn't work on Microsoft's Windows Subsystem for Linux (WSL). You get back -1/EINVAL. - Is probably specific to user threads? - Fails to put a useful message in the assert other than "FALSE" Proposals: 1. Remove it. 2. Make it check for and ignore EINVAL, and possibly WSL, and not then enable in child. 3. Change it to get in parent and set in child if enabled. 4. Move it to Thread.AtFork in user threads. Though again, not clearly needed there. 5. Consider that fork+exec should work from C/C++ code in a process that is using Modula3. 6. Research posix_spawn and use it more. We can probably just use it and forget about any system that lacks it. Thoughts? WSL can be detected by searching for "Microsoft" in /proc/sys/kernel/osrelease or /proc/version. Or we can just accept -1/EINVAL here for any OS. - Jay _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcchu at acm.org Sat Aug 26 02:55:20 2017 From: jcchu at acm.org (JC Chu) Date: Sat, 26 Aug 2017 00:55:20 +0000 Subject: [M3devel] [modula3/cm3] Quake scoping issue (#19) In-Reply-To: References: Message-ID: I understand from ?7.2 and your comment that, when ?m3makefile2? is included, it is interpreted inside the local scope created when `map_proc` is called, where `list` is not bound to a?procedure. In fact, even if ?m3makefile2? didn?t define `list` itself, the same error would still occur. (That said, if procedures can only be defined in the global scope, shouldn?t they only be searched there as well?) However, by the same argument, the behavior of the following makefile is a?bit unexpected to me. test_var = 0 readonly proc call (f, test_var) is return f() end readonly proc write_test_var () is write(format("test_var = %s\n"), test_var) end readonly proc eval (_) is end eval(call(write_test_var, 123)) Here, `write_test_var` is evaluated in its own scope, which is inside the scope of `call`, where `test_var` = 123. The actual output, though, is 0. ??JC -----Original Message----- From: Rodney M. Bates [mailto:rbatesjk at lcwb.coop] Sent: Friday, August 25, 2017 23:40 To: reply+00655cb4faee270b469769c158f8bcd114e2942747144a0292cf0000000115b6154992a169ce0f0c9468 at reply.github.com; m3devel ; jcchu >> JC Chu Subject: Re: [modula3/cm3] Quake scoping issue (#19) According to Quake, 7.3, "Procedures may be defined in the global scope only". Apparently, from experiment, this means that, although the procedure definition itself can be located inside a local scope, its name is declared in the global scope. So, if you don't import libm3, your 'list' declaration is not a duplicate, thus produces no error, and becomes declared in the global scope. But the call on 'list' resolves to the formal parameter 'list', of 'map_proc', which is found in the local scope, and whose value is the list '[ m3makefile2 ]', not a procedure, and thus not callable. Any suitable renaming of either the parameter or the procedure, so that the two meanings of 'list' have different names, works as expected. I'll grant that having a procedure declaration located in a local scope but declaring its name in the global one is peculiar, and this is a peculiar effect of that rule. I have made a note to explain this better in the Quake documentation. On 08/23/2017 11:17 PM, jcchu wrote: > See demo.zip . > > ? > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub , or mute the thread . > From rodney_bates at lcwb.coop Sat Aug 26 18:01:58 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 26 Aug 2017 11:01:58 -0500 Subject: [M3devel] [modula3/cm3] Quake scoping issue (#19) In-Reply-To: References: Message-ID: <8e769051-2da0-1375-021b-06e316ba6370@lcwb.coop> On 08/25/2017 07:55 PM, JC Chu wrote: > I understand from ?7.2 and your comment that, when ?m3makefile2? is included, it is interpreted inside the local scope created when `map_proc` is called, where `list` is not bound to a procedure. In fact, even if ?m3makefile2? didn?t define `list` itself, the same error would still occur. (That said, if procedures can only be defined in the global scope, shouldn?t they only be searched there as well?) > Well, I am not trying to justify or defend this language design, just understand what it is. This is indeed unusual. I don't recall ever seeing a language where the scope an indentifier is declared in is different from the scope the declaring code is located in. In fact, I find it very difficult to articulate this clearly, and I don't think the foregoing sentence does it very well. > However, by the same argument, the behavior of the following makefile is a bit unexpected to me. > > test_var = 0 > readonly proc call (f, test_var) is return f() end > readonly proc write_test_var () is > write(format("test_var = %s\n"), test_var) > end > readonly proc eval (_) is end > eval(call(write_test_var, 123)) > > Here, `write_test_var` is evaluated in its own scope, which is inside the scope of `call`, where `test_var` = 123. The actual output, though, is 0. > This makes complete sense to me, after a rather intense reading session. 'call' is called with 'write_test_var' and 123 as actual parameters corresponding to 'call's formals 'f' and 'test_var'. But 'call's body makes no reference to its formal 'test_var', so the 123 value is just lost. When execution gets into 'write_test_var', its containing scope is the global scope, where the global 'test_var' is the one found. Note that this is static scoping, not dynamic, which means the containing scope of 'write_test_var' is not the scope of its caller, but is determined by its textual location within the code, specifically, it is immediately inside the global scope. Dynamic scoping, e.g., in lisp, has turned out to be a source of intriguing puzzles, but far too confusing to be helpful to programming in general. It makes it too easy for something to change meaning unexpectedly, as result of being called from some place unknown to the writer of the procedure. > ? JC > > -----Original Message----- > From: Rodney M. Bates [mailto:rbatesjk at lcwb.coop] > Sent: Friday, August 25, 2017 23:40 > To: reply+00655cb4faee270b469769c158f8bcd114e2942747144a0292cf0000000115b6154992a169ce0f0c9468 at reply.github.com; m3devel ; jcchu >> JC Chu > Subject: Re: [modula3/cm3] Quake scoping issue (#19) > > According to Quake, 7.3, "Procedures may be defined in the global scope only". > Apparently, from experiment, this means that, although the procedure definition > itself can be located inside a local scope, its name is declared in the global > scope. > > So, if you don't import libm3, your 'list' declaration is not a duplicate, thus > produces no error, and becomes declared in the global scope. But the call on > 'list' resolves to the formal parameter 'list', of 'map_proc', which is found > in the local scope, and whose value is the list '[ m3makefile2 ]', not a > procedure, and thus not callable. > > Any suitable renaming of either the parameter or the procedure, so that the two > meanings of 'list' have different names, works as expected. > > I'll grant that having a procedure declaration located in a local scope but > declaring its name in the global one is peculiar, and this is a peculiar > effect of that rule. > > I have made a note to explain this better in the Quake documentation. > > On 08/23/2017 11:17 PM, jcchu wrote: >> See demo.zip . >> >> ? >> You are receiving this because you are subscribed to this thread. >> Reply to this email directly, view it on GitHub , or mute the thread . >> > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat Aug 26 18:40:41 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 26 Aug 2017 11:40:41 -0500 Subject: [M3devel] [modula3/cm3] Quake scoping issue (#19) In-Reply-To: References: Message-ID: This example suggests another point, not mentioned so far: test_var = 0 readonly proc P ( test_var ) is readonly proc Q ( ) is write(format("In Q, test_var = %s\n", test_var)) end %Q write(format("In P, test_var = %s\n", test_var)) Q ( ) end %P P (123) Q() Produces: --- building in ../AMD64_LINUX --- In P, test_var = 123 In Q, test_var = 0 In Q, test_var = 0 The decl of 'Q' is located inside 'P', but not only is its name ('Q') declared in the global scope, but also, nonlocal references inside 'Q' (e.g., 'test_var') are looked up directly in the global scope as well. It is if the entire decl of 'Q' were pulled outside of 'P'. Except..., for the matter of declare-before-use, which is probably as if the decl of 'Q' stayed where it is. At this point, I am feeling like this is starting to be too much attention to waste on the dark corners of the semantics of Quake. I have always felt the often bizarre and often ill-defined semantics of dynamically- typed, interpreted, scripting languages are inevitably a mess, and people should not be wasting so much time writing anything very complicated in any of them. The current fad of using Python to teach new young coders in schools is, IMO, very short-sighted. At least the designers of Quake admitted up front that it was only intended to have minimal capability, just adequate for the limited needs of the Modula3 build system. On 08/25/2017 07:55 PM, JC Chu wrote: > I understand from ?7.2 and your comment that, when ?m3makefile2? is included, it is interpreted inside the local scope created when `map_proc` is called, where `list` is not bound to a procedure. In fact, even if ?m3makefile2? didn?t define `list` itself, the same error would still occur. (That said, if procedures can only be defined in the global scope, shouldn?t they only be searched there as well?) > > However, by the same argument, the behavior of the following makefile is a bit unexpected to me. > > test_var = 0 > readonly proc call (f, test_var) is return f() end > readonly proc write_test_var () is > write(format("test_var = %s\n"), test_var) > end > readonly proc eval (_) is end > eval(call(write_test_var, 123)) > > Here, `write_test_var` is evaluated in its own scope, which is inside the scope of `call`, where `test_var` = 123. The actual output, though, is 0. > > ? JC > > -----Original Message----- > From: Rodney M. Bates [mailto:rbatesjk at lcwb.coop] > Sent: Friday, August 25, 2017 23:40 > To: reply+00655cb4faee270b469769c158f8bcd114e2942747144a0292cf0000000115b6154992a169ce0f0c9468 at reply.github.com; m3devel ; jcchu >> JC Chu > Subject: Re: [modula3/cm3] Quake scoping issue (#19) > > According to Quake, 7.3, "Procedures may be defined in the global scope only". > Apparently, from experiment, this means that, although the procedure definition > itself can be located inside a local scope, its name is declared in the global > scope. > > So, if you don't import libm3, your 'list' declaration is not a duplicate, thus > produces no error, and becomes declared in the global scope. But the call on > 'list' resolves to the formal parameter 'list', of 'map_proc', which is found > in the local scope, and whose value is the list '[ m3makefile2 ]', not a > procedure, and thus not callable. > > Any suitable renaming of either the parameter or the procedure, so that the two > meanings of 'list' have different names, works as expected. > > I'll grant that having a procedure declaration located in a local scope but > declaring its name in the global one is peculiar, and this is a peculiar > effect of that rule. > > I have made a note to explain this better in the Quake documentation. > > On 08/23/2017 11:17 PM, jcchu wrote: >> See demo.zip . >> >> ? >> You are receiving this because you are subscribed to this thread. >> Reply to this email directly, view it on GitHub , or mute the thread . >> > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From dabenavidesd at yahoo.es Sat Aug 26 21:29:18 2017 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 26 Aug 2017 19:29:18 +0000 (UTC) Subject: [M3devel] On the way to release other packages in GPL? References: <1323059193.3673624.1503775758492.ref@mail.yahoo.com> Message-ID: <1323059193.3673624.1503775758492@mail.yahoo.com> Hello:what if we ask to release all Modula-3 in GPL?https://www.dwheeler.com/misc/simplify-hp-release.txt Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcchu at acm.org Sun Aug 27 06:16:48 2017 From: jcchu at acm.org (JC Chu) Date: Sun, 27 Aug 2017 04:16:48 +0000 Subject: [M3devel] [modula3/cm3] Quake scoping issue (#19) In-Reply-To: References: Message-ID: > The current fad of using Python to teach new young coders in schools is, IMO, very short-sighted. Interestingly, Python is said to have been influenced by Modula-3. I?ve yet to see how. > At least the designers of Quake admitted up front that it was only intended to have minimal capability, just adequate for the limited needs of the Modula3 build system. I personally find the macro-like semantics of `include` and `include_dir` rather limiting for single packages involving multiple makefiles. The thing is, Quake is pretty much the only choice for building CM3 packages; if you don?t like it, you?re out of luck. ??JC -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Sunday, August 27, 2017 0:41 To: m3devel at elegosoft.com; JC Chu Subject: Re: [M3devel] [modula3/cm3] Quake scoping issue (#19) This example suggests another point, not mentioned so far: test_var = 0 readonly proc P ( test_var ) is readonly proc Q ( ) is write(format("In Q, test_var = %s\n", test_var)) end %Q write(format("In P, test_var = %s\n", test_var)) Q ( ) end %P P (123) Q() Produces: --- building in ../AMD64_LINUX --- In P, test_var = 123 In Q, test_var = 0 In Q, test_var = 0 The decl of 'Q' is located inside 'P', but not only is its name ('Q') declared in the global scope, but also, nonlocal references inside 'Q' (e.g., 'test_var') are looked up directly in the global scope as well. It is if the entire decl of 'Q' were pulled outside of 'P'. Except..., for the matter of declare-before-use, which is probably as if the decl of 'Q' stayed where it is. At this point, I am feeling like this is starting to be too much attention to waste on the dark corners of the semantics of Quake. I have always felt the often bizarre and often ill-defined semantics of dynamically- typed, interpreted, scripting languages are inevitably a mess, and people should not be wasting so much time writing anything very complicated in any of them. The current fad of using Python to teach new young coders in schools is, IMO, very short-sighted. At least the designers of Quake admitted up front that it was only intended to have minimal capability, just adequate for the limited needs of the Modula3 build system. On 08/25/2017 07:55 PM, JC Chu wrote: > I understand from ?7.2 and your comment that, when ?m3makefile2? is included, it is interpreted inside the local scope created when `map_proc` is called, where `list` is not bound to a procedure. In fact, even if ?m3makefile2? didn?t define `list` itself, the same error would still occur. (That said, if procedures can only be defined in the global scope, shouldn?t they only be searched there as well?) > > However, by the same argument, the behavior of the following makefile is a bit unexpected to me. > > test_var = 0 > readonly proc call (f, test_var) is return f() end > readonly proc write_test_var () is > write(format("test_var = %s\n"), test_var) > end > readonly proc eval (_) is end > eval(call(write_test_var, 123)) > > Here, `write_test_var` is evaluated in its own scope, which is inside the scope of `call`, where `test_var` = 123. The actual output, though, is 0. > > ? JC > > -----Original Message----- > From: Rodney M. Bates [mailto:rbatesjk at lcwb.coop] > Sent: Friday, August 25, 2017 23:40 > To: reply+00655cb4faee270b469769c158f8bcd114e2942747144a0292cf0000000115b6154992a169ce0f0c9468 at reply.github.com; m3devel ; jcchu >> JC Chu > Subject: Re: [modula3/cm3] Quake scoping issue (#19) > > According to Quake, 7.3, "Procedures may be defined in the global scope only". > Apparently, from experiment, this means that, although the procedure definition > itself can be located inside a local scope, its name is declared in the global > scope. > > So, if you don't import libm3, your 'list' declaration is not a duplicate, thus > produces no error, and becomes declared in the global scope. But the call on > 'list' resolves to the formal parameter 'list', of 'map_proc', which is found > in the local scope, and whose value is the list '[ m3makefile2 ]', not a > procedure, and thus not callable. > > Any suitable renaming of either the parameter or the procedure, so that the two > meanings of 'list' have different names, works as expected. > > I'll grant that having a procedure declaration located in a local scope but > declaring its name in the global one is peculiar, and this is a peculiar > effect of that rule. > > I have made a note to explain this better in the Quake documentation. > > On 08/23/2017 11:17 PM, jcchu wrote: >> See demo.zip . >> >> ? >> You are receiving this because you are subscribed to this thread. >> Reply to this email directly, view it on GitHub , or mute the thread . >> > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun Aug 27 18:33:41 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 27 Aug 2017 11:33:41 -0500 Subject: [M3devel] [M3commit] [modula3/cm3] 90b335: Fix special-case passing of static link parameter. In-Reply-To: References: <599f54154613a_2df23fb8742fbc3490913@hookshot-fe2-cp1-prd.iad.github.net.mail> Message-ID: <9ab52210-0ad4-0221-3f28-509547b882cb@lcwb.coop> I really would not have expected gcc and C backends to interoperate in this way, while still working with a range of standard C compilers. In fact, I am gratifyingly surprised gcc and llvm backends do. But this does not detract from the C backend's major goal of simplifying porting and bootstrapping on new machines and architectures. What I would be really love to have is inter-language binary compatibility between Modula3 and C++ dispatching method calls, at least in the absence of multiple inheritance. But that would probably be quite difficult and entail changes in Modula3's current runtime model--a big and disruptive job. On 08/24/2017 06:27 PM, Jay K wrote: > Fyi the C backend completely works here, but everything must be compiled with the same backend, and gcc and C backend do not interoperate -- they pass the static link differently. > > - Jay > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3commit on behalf of GitHub > *Sent:* Thursday, August 24, 2017 3:32:53 PM > *To:* m3commit at elegosoft.com > *Subject:* [M3commit] [modula3/cm3] 90b335: Fix special-case passing of static link parameter. > > Branch: refs/heads/master > Home: https://github.com/modula3/cm3 > Commit: 90b335e7ae53393d9dfc78f690e39a7cad49e086 > https://github.com/modula3/cm3/commit/90b335e7ae53393d9dfc78f690e39a7cad49e086 > Author: Rodney Bates > Date: 2017-08-24 (Thu, 24 Aug 2017) > > Changed paths: > M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 > > Log Message: > ----------- > Fix special-case passing of static link parameter. > > Add the llvm 'nest' attribute to the static link parameter, both > for direct and indirect calls. This causes llvm to pass this > parameter in the way the target ABI specifies for a static link. > Without this, everything was almost working except for execution > of a finally block when an exception propagated through it. This > would probably have worked too, if the runtime were also compiled > with the llvm backend. But RTExFrame passes a static link to user > code, and, if compiled by different back ends, these were using > different parameter conventions. > > With this change, all test cases that pass using the gcc back end > also pass using the llvm backend, plus one more (p140). Also, llvm > incorrectly shows a failure on p004. This is only a reordering > of warning messages produced by the front end, which is asked to > unnest nested procedures in different order by these two back ends. > > This is with mixing m3cc-compiled runtime and llvm-compiled test > cases, which bodes well for interoperability of these back ends. > > > > > _______________________________________________ > M3commit mailing list > M3commit at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3commit > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun Aug 27 18:51:34 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 27 Aug 2017 11:51:34 -0500 Subject: [M3devel] [modula3/cm3] Quake scoping issue (#19) In-Reply-To: References: <8e769051-2da0-1375-021b-06e316ba6370@lcwb.coop> Message-ID: On 08/26/2017 08:18 PM, JC Chu wrote: >> Note that this is static scoping, not dynamic, which means the containing scope of 'write_test_var' is not the scope of its caller, but is determined by its textual location within the code, specifically, it is immediately inside the global scope. > > Hmm, let?s see if I understand this whole thing correctly. The procedure `include`, according to Quake doc ?9.2, performs in-place expansion, like a macro. When a makefile is expanded from within a procedure, as in my first example, it?s interpreted against that procedure?s local scope, where global identifiers may be overridden. This may give the false impression that Quake is not statically scoped, which is then refuted by my second example. > The textual inclusion is not really relevant. It's entirely the bizarre semantics of a procedure definition occurring inside an inner scope such as another procedure of a for statement. It doesn't matter whether/how inclusion was involved in getting the "nested" procedure into its nested position. It would seem so much more sensible to just disallow a procedure definition altogether in a nested position. That would have meant included Quake code that declared its own procedure(s) could only be included from directly inside the global scope. Would that be such a burdensome restriction? Actually, maybe the designers intended it to be that way, but the implementation just has a bug not enforcing the rule. In fact, the language definition said (before my update to it just now) "Procedures may be defined in the global scope only.", which really ought to be interpreted to mean just what I am suggesting. I wonder how much existing Quake code would break if we did that? > ? JC > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Sunday, August 27, 2017 0:02 > To: m3devel at elegosoft.com; JC Chu > Subject: Re: [M3devel] [modula3/cm3] Quake scoping issue (#19) > > > > On 08/25/2017 07:55 PM, JC Chu wrote: >> I understand from ?7.2 and your comment that, when ?m3makefile2? is included, it is interpreted inside the local scope created when `map_proc` is called, where `list` is not bound to a procedure. In fact, even if ?m3makefile2? didn?t define `list` itself, the same error would still occur. (That said, if procedures can only be defined in the global scope, shouldn?t they only be searched there as well?) >> > > Well, I am not trying to justify or defend this language design, just understand what it is. > This is indeed unusual. I don't recall ever seeing a language where the scope an indentifier > is declared in is different from the scope the declaring code is located in. In fact, I find > it very difficult to articulate this clearly, and I don't think the foregoing sentence does it > very well. > >> However, by the same argument, the behavior of the following makefile is a bit unexpected to me. >> >> test_var = 0 >> readonly proc call (f, test_var) is return f() end >> readonly proc write_test_var () is >> write(format("test_var = %s\n"), test_var) >> end >> readonly proc eval (_) is end >> eval(call(write_test_var, 123)) >> >> Here, `write_test_var` is evaluated in its own scope, which is inside the scope of `call`, where `test_var` = 123. The actual output, though, is 0. >> > > This makes complete sense to me, after a rather intense reading session. 'call' is called > with 'write_test_var' and 123 as actual parameters corresponding to 'call's formals 'f' > and 'test_var'. But 'call's body makes no reference to its formal 'test_var', so the 123 value > is just lost. When execution gets into 'write_test_var', its containing scope is the global > scope, where the global 'test_var' is the one found. > > Note that this is static scoping, not dynamic, which means the containing scope of 'write_test_var' > is not the scope of its caller, but is determined by its textual location within the code, > specifically, it is immediately inside the global scope. > > Dynamic scoping, e.g., in lisp, has turned out to be a source of intriguing puzzles, but far > too confusing to be helpful to programming in general. It makes it too easy for something to > change meaning unexpectedly, as result of being called from some place unknown to the writer > of the procedure. > >> ? JC >> >> -----Original Message----- >> From: Rodney M. Bates [mailto:rbatesjk at lcwb.coop] >> Sent: Friday, August 25, 2017 23:40 >> To: reply+00655cb4faee270b469769c158f8bcd114e2942747144a0292cf0000000115b6154992a169ce0f0c9468 at reply.github.com; m3devel ; jcchu >> JC Chu >> Subject: Re: [modula3/cm3] Quake scoping issue (#19) >> >> According to Quake, 7.3, "Procedures may be defined in the global scope only". >> Apparently, from experiment, this means that, although the procedure definition >> itself can be located inside a local scope, its name is declared in the global >> scope. >> >> So, if you don't import libm3, your 'list' declaration is not a duplicate, thus >> produces no error, and becomes declared in the global scope. But the call on >> 'list' resolves to the formal parameter 'list', of 'map_proc', which is found >> in the local scope, and whose value is the list '[ m3makefile2 ]', not a >> procedure, and thus not callable. >> >> Any suitable renaming of either the parameter or the procedure, so that the two >> meanings of 'list' have different names, works as expected. >> >> I'll grant that having a procedure declaration located in a local scope but >> declaring its name in the global one is peculiar, and this is a peculiar >> effect of that rule. >> >> I have made a note to explain this better in the Quake documentation. >> >> On 08/23/2017 11:17 PM, jcchu wrote: >>> See demo.zip . >>> >>> ? >>> You are receiving this because you are subscribed to this thread. >>> Reply to this email directly, view it on GitHub , or mute the thread . >>> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel >> > -- Rodney Bates rodney.m.bates at acm.org From hendrik at topoi.pooq.com Mon Aug 28 01:40:46 2017 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 27 Aug 2017 19:40:46 -0400 Subject: [M3devel] On the way to release other packages in GPL? In-Reply-To: <1323059193.3673624.1503775758492@mail.yahoo.com> References: <1323059193.3673624.1503775758492.ref@mail.yahoo.com> <1323059193.3673624.1503775758492@mail.yahoo.com> Message-ID: <20170827234046.GB31000@topoi.pooq.com> On Sat, Aug 26, 2017 at 07:29:18PM +0000, Daniel Alejandro Benavides D. wrote: > Hello:what if we ask to release all Modula-3 in GPL?https://www.dwheeler.com/misc/simplify-hp-release.txt > Thanks in advance You can release every package *you*write using the GPL. But you'll have licence compatibility issues because the majority of Modula 3 code is not covered by the GPL unless you also release it under a license compatible with the one that most of the Modula 3 stuff is licenced under. There's nothing difficult about having two licences. It just means there are two possible conditions under which someone can use and copy them. Its enough for either to apply, and it gets out of bothersome licence compatbility restrictions. -- hendrik From jayk123 at hotmail.com Mon Aug 28 02:18:40 2017 From: jayk123 at hotmail.com (Jay K) Date: Mon, 28 Aug 2017 00:18:40 +0000 Subject: [M3devel] On the way to release other packages in GPL? In-Reply-To: <20170827234046.GB31000@topoi.pooq.com> References: <1323059193.3673624.1503775758492.ref@mail.yahoo.com> <1323059193.3673624.1503775758492@mail.yahoo.com>, <20170827234046.GB31000@topoi.pooq.com> Message-ID: Please no GPL. I want it all BSD, and one license for it all. Including the m3cg.h or such that I wrote that is currently GPL. I'll send mail on it later. Dual license might be required. This file in particular is C preprocessor code that helps read our IR. I'd also like to BSD parse.c but not clear we can. Try & see if anyone objects? Surely nobody will. - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Sunday, August 27, 2017 4:40:46 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] On the way to release other packages in GPL? On Sat, Aug 26, 2017 at 07:29:18PM +0000, Daniel Alejandro Benavides D. wrote: > Hello:what if we ask to release all Modula-3 in GPL?https://www.dwheeler.com/misc/simplify-hp-release.txt > Thanks in advance You can release every package *you*write using the GPL. But you'll have licence compatibility issues because the majority of Modula 3 code is not covered by the GPL unless you also release it under a license compatible with the one that most of the Modula 3 stuff is licenced under. There's nothing difficult about having two licences. It just means there are two possible conditions under which someone can use and copy them. Its enough for either to apply, and it gets out of bothersome licence compatbility restrictions. -- hendrik _______________________________________________ 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 Mon Aug 28 02:59:27 2017 From: jayk123 at hotmail.com (Jay K) Date: Mon, 28 Aug 2017 00:59:27 +0000 Subject: [M3devel] [M3commit] [modula3/cm3] 90b335: Fix special-case passing of static link parameter. In-Reply-To: <9ab52210-0ad4-0221-3f28-509547b882cb@lcwb.coop> References: <599f54154613a_2df23fb8742fbc3490913@hookshot-fe2-cp1-prd.iad.github.net.mail> , <9ab52210-0ad4-0221-3f28-509547b882cb@lcwb.coop> Message-ID: 1. Thank you-- the C backend is under-understood & under appreciated. 2. This should be easy -- Modula-3 object methods are presumably like C++ virtual member functions. There are some challenges to interop. One would want cm3 to generate headers & maybe glue code-- stuff around GC. - Jay ________________________________ From: Rodney M. Bates Sent: Sunday, August 27, 2017 9:33:41 AM To: m3devel; Jay Subject: Re: [M3commit] [modula3/cm3] 90b335: Fix special-case passing of static link parameter. I really would not have expected gcc and C backends to interoperate in this way, while still working with a range of standard C compilers. In fact, I am gratifyingly surprised gcc and llvm backends do. But this does not detract from the C backend's major goal of simplifying porting and bootstrapping on new machines and architectures. What I would be really love to have is inter-language binary compatibility between Modula3 and C++ dispatching method calls, at least in the absence of multiple inheritance. But that would probably be quite difficult and entail changes in Modula3's current runtime model--a big and disruptive job. On 08/24/2017 06:27 PM, Jay K wrote: > Fyi the C backend completely works here, but everything must be compiled with the same backend, and gcc and C backend do not interoperate -- they pass the static link differently. > > - Jay > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3commit on behalf of GitHub > *Sent:* Thursday, August 24, 2017 3:32:53 PM > *To:* m3commit at elegosoft.com > *Subject:* [M3commit] [modula3/cm3] 90b335: Fix special-case passing of static link parameter. > > Branch: refs/heads/master > Home: https://github.com/modula3/cm3 > Commit: 90b335e7ae53393d9dfc78f690e39a7cad49e086 > https://github.com/modula3/cm3/commit/90b335e7ae53393d9dfc78f690e39a7cad49e086 > Author: Rodney Bates > Date: 2017-08-24 (Thu, 24 Aug 2017) > > Changed paths: > M m3-sys/llvm3.6.1/src/M3CG_LLVM.m3 > > Log Message: > ----------- > Fix special-case passing of static link parameter. > > Add the llvm 'nest' attribute to the static link parameter, both > for direct and indirect calls. This causes llvm to pass this > parameter in the way the target ABI specifies for a static link. > Without this, everything was almost working except for execution > of a finally block when an exception propagated through it. This > would probably have worked too, if the runtime were also compiled > with the llvm backend. But RTExFrame passes a static link to user > code, and, if compiled by different back ends, these were using > different parameter conventions. > > With this change, all test cases that pass using the gcc back end > also pass using the llvm backend, plus one more (p140). Also, llvm > incorrectly shows a failure on p004. This is only a reordering > of warning messages produced by the front end, which is asked to > unnest nested procedures in different order by these two back ends. > > This is with mixing m3cc-compiled runtime and llvm-compiled test > cases, which bodes well for interoperability of these back ends. > > > > > _______________________________________________ > M3commit mailing list > M3commit at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3commit > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 28 07:11:55 2017 From: jayk123 at hotmail.com (Jay K) Date: Mon, 28 Aug 2017 05:11:55 +0000 Subject: [M3devel] On the way to release other packages in GPL? In-Reply-To: <8381B1BB-75DE-41D1-8DE1-65B788471E5D@purdue.edu> References: <1323059193.3673624.1503775758492.ref@mail.yahoo.com> <1323059193.3673624.1503775758492@mail.yahoo.com> <20170827234046.GB31000@topoi.pooq.com> , <8381B1BB-75DE-41D1-8DE1-65B788471E5D@purdue.edu> Message-ID: So, I think 1. Modula-3 maybe matters less these days? 2. It is the code owners that would have to object, right? - Jay ________________________________ From: Hosking, Antony L Sent: Sunday, August 27, 2017 10:06:46 PM To: Jay K Cc: Hendrik Boom; m3devel at elegosoft.com Subject: Re: [M3devel] On the way to release other packages in GPL? On Aug 28, 2017, at 10:18 AM, Jay K > wrote: Please no GPL. I want it all BSD, and one license for it all. Including the m3cg.h or such that I wrote that is currently GPL. I'll send mail on it later. Dual license might be required. This file in particular is C preprocessor code that helps read our IR. I'd also like to BSD parse.c but not clear we can. Try & see if anyone objects? Surely nobody will. RMS himself hit the roof when the original M3CG front-end to gcc was done, as he saw it as a threat to GPL. So, I wouldn?t count on that. - Jay ________________________________ From: M3devel > on behalf of Hendrik Boom > Sent: Sunday, August 27, 2017 4:40:46 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] On the way to release other packages in GPL? On Sat, Aug 26, 2017 at 07:29:18PM +0000, Daniel Alejandro Benavides D. wrote: > Hello:what if we ask to release all Modula-3 in GPL?https://www.dwheeler.com/misc/simplify-hp-release.txt > Thanks in advance You can release every package *you*write using the GPL. But you'll have licence compatibility issues because the majority of Modula 3 code is not covered by the GPL unless you also release it under a license compatible with the one that most of the Modula 3 stuff is licenced under. There's nothing difficult about having two licences. It just means there are two possible conditions under which someone can use and copy them. Its enough for either to apply, and it gets out of bothersome licence compatbility restrictions. -- hendrik _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcchu at acm.org Mon Aug 28 16:59:38 2017 From: jcchu at acm.org (JC Chu) Date: Mon, 28 Aug 2017 14:59:38 +0000 Subject: [M3devel] [modula3/cm3] Quake scoping issue (#19) In-Reply-To: References: <8e769051-2da0-1375-021b-06e316ba6370@lcwb.coop> Message-ID: > The textual inclusion is not really relevant. It's entirely the bizarre semantics of a procedure definition occurring inside an inner scope such as another procedure of a for statement. It doesn't matter whether/how inclusion was involved in getting the "nested" procedure into its nested position. Yeah. I was talking about why `list` was overriden and became an?array in the first example (because of ?include?) while `test_var` was not overriden in the second example (because of how scoping works); no procedure definitions was involved so far. > It would seem so much more sensible to just disallow a procedure definition altogether in a nested position. That would have meant included Quake code that declared its own procedure(s) could only be included from directly inside the global scope. Would that be such a burdensome restriction? Upon a?second look, the semantics of nested procedure declarations doesn?t seem entirely bizarre to me. The current rule seems to be that any identifier not declared locally is searched _only_ in the global scope, as the following example shows (based on your previous example). test_var = 0 proc P (test_var) is write(format("P: (%s, %s)\n", test_var, test_var_2)) proc Q () is write(format("Q: (%s, %s)\n", test_var, test_var_2)) end return Q end proc test () is test_var_2 = 456 local test_var_2 = 654 % no effect local q = P(123) q() end test() In other words, at any point, there are only two possible scopes: local (to the current procedure only, not nested ones) and global. This rule implies that all procedures will behave as if they were declared in the global scope. It also seems to be the reason why procedures ?may be defined in the global scope only? (at least by the book). With the identifier searching rule in mind, I don?t think procedures in nested positions necessarily cause any confusion or should be forbidden. Instead, the real culprit is the macro-like behavior of `include` and `include_dir` (and arguably `quake`), which can cause global identifiers to be overridden when the inclusion is non-global. ??JC -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Monday, August 28, 2017 0:52 To: JC Chu ; m3devel at elegosoft.com; JC Chu Subject: Re: [M3devel] [modula3/cm3] Quake scoping issue (#19) On 08/26/2017 08:18 PM, JC Chu wrote: >> Note that this is static scoping, not dynamic, which means the containing scope of 'write_test_var' is not the scope of its caller, but is determined by its textual location within the code, specifically, it is immediately inside the global scope. > > Hmm, let?s see if I understand this whole thing correctly. The procedure `include`, according to Quake doc ?9.2, performs in-place expansion, like a macro. When a makefile is expanded from within a procedure, as in my first example, it?s interpreted against that procedure?s local scope, where global identifiers may be overridden. This may give the false impression that Quake is not statically scoped, which is then refuted by my second example. > The textual inclusion is not really relevant. It's entirely the bizarre semantics of a procedure definition occurring inside an inner scope such as another procedure of a for statement. It doesn't matter whether/how inclusion was involved in getting the "nested" procedure into its nested position. It would seem so much more sensible to just disallow a procedure definition altogether in a nested position. That would have meant included Quake code that declared its own procedure(s) could only be included from directly inside the global scope. Would that be such a burdensome restriction? Actually, maybe the designers intended it to be that way, but the implementation just has a bug not enforcing the rule. In fact, the language definition said (before my update to it just now) "Procedures may be defined in the global scope only.", which really ought to be interpreted to mean just what I am suggesting. I wonder how much existing Quake code would break if we did that? > ? JC > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Sunday, August 27, 2017 0:02 > To: m3devel at elegosoft.com; JC Chu > Subject: Re: [M3devel] [modula3/cm3] Quake scoping issue (#19) > > > > On 08/25/2017 07:55 PM, JC Chu wrote: >> I understand from ?7.2 and your comment that, when ?m3makefile2? is included, it is interpreted inside the local scope created when `map_proc` is called, where `list` is not bound to a procedure. In fact, even if ?m3makefile2? didn?t define `list` itself, the same error would still occur. (That said, if procedures can only be defined in the global scope, shouldn?t they only be searched there as well?) >> > > Well, I am not trying to justify or defend this language design, just understand what it is. > This is indeed unusual. I don't recall ever seeing a language where the scope an indentifier > is declared in is different from the scope the declaring code is located in. In fact, I find > it very difficult to articulate this clearly, and I don't think the foregoing sentence does it > very well. > >> However, by the same argument, the behavior of the following makefile is a bit unexpected to me. >> >> test_var = 0 >> readonly proc call (f, test_var) is return f() end >> readonly proc write_test_var () is >> write(format("test_var = %s\n"), test_var) >> end >> readonly proc eval (_) is end >> eval(call(write_test_var, 123)) >> >> Here, `write_test_var` is evaluated in its own scope, which is inside the scope of `call`, where `test_var` = 123. The actual output, though, is 0. >> > > This makes complete sense to me, after a rather intense reading session. 'call' is called > with 'write_test_var' and 123 as actual parameters corresponding to 'call's formals 'f' > and 'test_var'. But 'call's body makes no reference to its formal 'test_var', so the 123 value > is just lost. When execution gets into 'write_test_var', its containing scope is the global > scope, where the global 'test_var' is the one found. > > Note that this is static scoping, not dynamic, which means the containing scope of 'write_test_var' > is not the scope of its caller, but is determined by its textual location within the code, > specifically, it is immediately inside the global scope. > > Dynamic scoping, e.g., in lisp, has turned out to be a source of intriguing puzzles, but far > too confusing to be helpful to programming in general. It makes it too easy for something to > change meaning unexpectedly, as result of being called from some place unknown to the writer > of the procedure. > >> ? JC >> >> -----Original Message----- >> From: Rodney M. Bates [mailto:rbatesjk at lcwb.coop] >> Sent: Friday, August 25, 2017 23:40 >> To: reply+00655cb4faee270b469769c158f8bcd114e2942747144a0292cf0000000115b6154992a169ce0f0c9468 at reply.github.com; m3devel ; jcchu >> JC Chu >> Subject: Re: [modula3/cm3] Quake scoping issue (#19) >> >> According to Quake, 7.3, "Procedures may be defined in the global scope only". >> Apparently, from experiment, this means that, although the procedure definition >> itself can be located inside a local scope, its name is declared in the global >> scope. >> >> So, if you don't import libm3, your 'list' declaration is not a duplicate, thus >> produces no error, and becomes declared in the global scope. But the call on >> 'list' resolves to the formal parameter 'list', of 'map_proc', which is found >> in the local scope, and whose value is the list '[ m3makefile2 ]', not a >> procedure, and thus not callable. >> >> Any suitable renaming of either the parameter or the procedure, so that the two >> meanings of 'list' have different names, works as expected. >> >> I'll grant that having a procedure declaration located in a local scope but >> declaring its name in the global one is peculiar, and this is a peculiar >> effect of that rule. >> >> I have made a note to explain this better in the Quake documentation. >> >> On 08/23/2017 11:17 PM, jcchu wrote: >>> See demo.zip . >>> >>> ? >>> You are receiving this because you are subscribed to this thread. >>> Reply to this email directly, view it on GitHub , or mute the thread . >>> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel >> > -- Rodney Bates rodney.m.bates at acm.org From dabenavidesd at yahoo.es Mon Aug 28 19:27:16 2017 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 28 Aug 2017 17:27:16 +0000 (UTC) Subject: [M3devel] On the way to release other packages in GPL? In-Reply-To: References: <1323059193.3673624.1503775758492.ref@mail.yahoo.com> <1323059193.3673624.1503775758492@mail.yahoo.com> <20170827234046.GB31000@topoi.pooq.com> <8381B1BB-75DE-41D1-8DE1-65B788471E5D@purdue.edu> Message-ID: <239249321.5067398.1503941236042@mail.yahoo.com> Hello:I fear most viable way to keep te language alive is to GPL it . Soon we wont have the resortes to keep alive. Im not understimating anyone here. But IMHO is de time to do it.?Thanks in advance Enviado desde Yahoo Mail para Android El lun, 28 de ago de 2017 a la(s) 0:12, Jay K escribi?: So, I think?1. Modula-3 maybe matters less these days?2. It is the code owners that would have to object, right? - JayFrom: Hosking, Antony L Sent: Sunday, August 27, 2017 10:06:46 PM To: Jay K Cc: Hendrik Boom; m3devel at elegosoft.com Subject: Re: [M3devel] On the way to release other packages in GPL?? On Aug 28, 2017, at 10:18 AM, Jay K wrote: Please no GPL.I want it all BSD, and one license for it all. Including the m3cg.h or such that I wrote that is currently GPL. I'll send mail on it later. Dual license might be required. This file in particular is C preprocessor code that helps read our IR. I'd also like to BSD parse.c but not clear we can. Try & see if anyone objects? Surely nobody will. RMS himself hit the roof when the original M3CG front-end to gcc was done, as he saw it as a threat to GPL. ?So, I wouldn?t count on that. - JayFrom:?M3devel on behalf of Hendrik Boom Sent:?Sunday, August 27, 2017 4:40:46 PM To:?m3devel at elegosoft.com Subject:?Re: [M3devel] On the way to release other packages in GPL??On Sat, Aug 26, 2017 at 07:29:18PM +0000, Daniel Alejandro Benavides D. wrote: > Hello:what if we ask to release all Modula-3 in GPL?https://www.dwheeler.com/misc/simplify-hp-release.txt > Thanks in advance You can release every package *you*write using the GPL. But you'll have licence compatibility issues because the majority of? Modula 3 code is not covered by the GPL unless you also release it? under a license compatible with the one that most of the Modula 3? stuff is licenced under. There's nothing difficult about having two licences.? It just means? there are two possible conditions under which someone can use and copy? them.? Its enough for either to apply, and it gets out of bothersome? licence compatbility restrictions. -- hendrik _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Aug 28 20:05:49 2017 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 28 Aug 2017 14:05:49 -0400 Subject: [M3devel] On the way to release other packages in GPL? In-Reply-To: <239249321.5067398.1503941236042@mail.yahoo.com> References: <1323059193.3673624.1503775758492.ref@mail.yahoo.com> <1323059193.3673624.1503775758492@mail.yahoo.com> <20170827234046.GB31000@topoi.pooq.com> <8381B1BB-75DE-41D1-8DE1-65B788471E5D@purdue.edu> <239249321.5067398.1503941236042@mail.yahoo.com> Message-ID: <20170828180549.GA14224@topoi.pooq.com> On Mon, Aug 28, 2017 at 05:27:16PM +0000, Daniel Alejandro Benavides D. wrote: > Hello:I fear most viable way to keep te language alive is to GPL it . Soon we wont have the resortes to keep alive. Im not understimating anyone here. But IMHO is de time to do it.?Thanks in advance Any GPL-compatible license will work. Even MIT. Possibly even the so-called Creative Commons variation on public domain, which is meaningful in jurisdictions without a concept of public domain. The hard part is liberating the parts of the system that are currently inder the existing Modula 3 license. They will have to be replaced if we can't get the copyright owner to respond usefully. And that's a lot of work. -- hendrik From rodney_bates at lcwb.coop Mon Aug 28 21:10:37 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 28 Aug 2017 14:10:37 -0500 Subject: [M3devel] [M3commit] [modula3/cm3] 90b335: Fix special-case passing of static link parameter. In-Reply-To: References: <599f54154613a_2df23fb8742fbc3490913@hookshot-fe2-cp1-prd.iad.github.net.mail> <9ab52210-0ad4-0221-3f28-509547b882cb@lcwb.coop> Message-ID: <0c91ef24-0f79-85c5-fc41-0d9b89465af1@lcwb.coop> On 08/27/2017 09:56 PM, Hosking, Antony L wrote: > Rodney, > > Can you give a summary of the status of the LLVM backend? Status of the Cm3 llvm backend. 2017-08-28 The llvm backend passes all of the compiler p tests in m3-sys/m3tests that the m3cc backend passes. This has been tried only for AMD64_LINUX. One of these (p004) complains of compile-time output different from what it expects, but this is only a different order of the same list of warning messages, no doubt due to the fact that these two backends request different orderings of unnesting of nested procedures. It's the same front end. Another (p140) is passing with llvm and not with m3cc. I thought I recalled once using the llvm backend to rebuild the compiler and core libraries twice, converging to same-sized executables and libraries. But more recently, this process failed in the second rebuild. m3llvm uses llvm version 3.6.1. The llvm project has just tagged a release candidate 5.0.0-rc3. They continue in very rapid development, and it is probably hard to track. Particularly painful is the production of bindings so our m3llvm pass can call into llvm to build its IR. This is extremely tedious and error prone. I would love it if I never had to do it again. The interface for debug info has changed significantly since the binding I created for 3.6.1. It would be very desirable if this could be automated. This may be already possible. Llvm in-memory IR has complex hierarchies of subclasses. Types in each such hierarchy are entirely lost by bindings, pointers being passed in and out statically typed as the top of the hierarchy. They receive the C++ equivalent of a NARROW when passed back in, which turns what could have been compile-time errors into runtime errors. It would be very desirable for this info to survive inter-language calls. The llvm backend requires a local build of llvm, using some of its libraries and executables. Figuring out which ones to link to and in what order is tedious, and failure messages give little clue to what is needed. There are currently no modifications to the llvm code, but a few are needed and look to be difficult to avoid. I have made no attempt to integrate building llvm into the cm3 build process. I guess I need to write some instructions for doing it. However, the process of compiling using llvm, given an installed llvm, is fully integrated into Cm3. Llvm is large, and time-consuming to build. Also, it compiles noticeably slower than m3cc, but this is probably to be expected, given its emphasis on optimization. No doubt different optimization levels are involved here. Generation of Dwarf debug info suffers some compile-time segfaults, and I have this disabled for now. The result is no debug info at all, so both gdb and m3gdb are limited to things like examining registers, disassembling machine code, etc. I have been able to get some use from even this. Most of the code for Dwarf production is present. It just needs some work. Maybe not too much. Once Dwarf is produced, it will probably not create a very Modula3- like debugging experience without considerable work in m3gdb, which now uses a greatly kludged extension of stabs. But even stock gcc will probably be better than it is now with stabs, perhaps quite a bit. The current scheme for handling up-level references is not very nice. It uses a variation on the old display scheme. It works for compiled code, but will not support up-level references made from a debugger to variables that are not already up-level referenced by the code itself. What is needed to get the displacements of locals through llvm is unclear. There was something added to a later llvm that might help. There still needs to be some thought given to who (CG or llvm) takes care of memory layout tasks. As with m3cc, the front end has lowered some things farther than llvm's IR is designed to expect. One llvm developer once said he would never let llvm do memory layout, but I am far from clear on the options and their consequences, particularly to optimization. Most of the llvm back end is in package m3-sys/m3llvm3.6.1. This compiles to an executable named 'm3llvm', a separate pass that reads Cm3' binary IR (*.ic, *.mc files) and writes llvm binary IR files (*.ib, *.mb). It makes calls on various llvm libraries through bindings found in package m3-sys/llvmbindings. Ignore packages llvm and llvmgen. They are old development stuff. Cm3 invokes m3llvm, llc (an llvm executable that reads llvm IR and produces assembly code) and as to assemble it. To compile using llvm, add the line: M3_BACKEND_MODE="StAloneLlvmAsm" to your cm3.cfg file to. > > ? Tony > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Mon Aug 28 21:25:27 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 28 Aug 2017 14:25:27 -0500 Subject: [M3devel] [M3commit] [modula3/cm3] 90b335: Fix special-case passing of static link parameter. In-Reply-To: References: <599f54154613a_2df23fb8742fbc3490913@hookshot-fe2-cp1-prd.iad.github.net.mail> <9ab52210-0ad4-0221-3f28-509547b882cb@lcwb.coop> Message-ID: <60bc31f6-d49f-e703-b347-43b5cc537082@lcwb.coop> On 08/27/2017 07:59 PM, Jay K wrote: > 1. Thank you-- the C backend is under-understood & under appreciated. > You're welcome. > 2. This should be easy -- Modula-3 > object methods are presumably like C++ virtual member functions. > There are some challenges to interop. One would want cm3 > to generate headers & maybe glue code-- stuff around GC. I think of two things. 1. Dispatching method calls. There is the C++ vtable mechanism that I have never looked at. It seems to be a runtime description of types, and it is unclear whether it is purely implementation, or whether the language itself must have some knowledge. I can hardly imagine that our runtime dispatching mechanism is binary compatible. Fortunately, we have only one. I'm not sure if that is true of the many C++ compilers. 2. Runtime type checks, NARROW, ISTYPE, TYPECASE, and their C++ equivalents. These would have to use the same runtime depiction of types too. This would greatly improve the safely of bindings, which now must lose this information entirely. Other things don't seem as daunting. > > - Jay > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Rodney M. Bates > *Sent:* Sunday, August 27, 2017 9:33:41 AM > *To:* m3devel; Jay > *Subject:* Re: [M3commit] [modula3/cm3] 90b335: Fix special-case passing of static link parameter. > > I really would not have expected gcc and C backends to interoperate in this way, while > still working with a range of standard C compilers. In fact, I am gratifyingly surprised > gcc and llvm backends do. But this does not detract from the C backend's major goal > of simplifying porting and bootstrapping on new machines and architectures. > > What I would be really love to have is inter-language binary compatibility between Modula3 > and C++ dispatching method calls, at least in the absence of multiple inheritance. But > that would probably be quite difficult and entail changes in Modula3's current runtime > model--a big and disruptive job. > > On 08/24/2017 06:27 PM, Jay K wrote: >> Fyi the C backend completely works here, but everything must be compiled with the same backend, and gcc and C backend do not interoperate -- they pass the static link differently. >> >> - Jay-- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Mon Aug 28 21:55:27 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 28 Aug 2017 14:55:27 -0500 Subject: [M3devel] [modula3/cm3] Quake scoping issue (#19) In-Reply-To: References: Message-ID: On 08/25/2017 07:55 PM, JC Chu wrote: > I understand from ?7.2 and your comment that, when ?m3makefile2? is included, it is interpreted inside the local scope created when `map_proc` is called, where `list` is not bound to a procedure. In fact, even if ?m3makefile2? didn?t define `list` itself, the same error would still occur. (That said, if procedures can only be defined in the global scope, shouldn?t they only be searched there as well?) > > However, by the same argument, the behavior of the following makefile is a bit unexpected to me. > > test_var = 0 > readonly proc call (f, test_var) is return f() end > readonly proc write_test_var () is > write(format("test_var = %s\n"), test_var) > end > readonly proc eval (_) is end > eval(call(write_test_var, 123)) > > Here, `write_test_var` is evaluated in its own scope, which is inside the scope of `call`, where `test_var` = 123. The actual output, though, is 0. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > No, you are trying to apply dynamic scoping interpretation. In dynamic scoping, the next outer scope around a procedure is its caller, as your statement says, and which can vary with different calls. In static scoping, the next outer scope of a procedure is determined solely by the textual location of its definition, not where it's called from. So the only scope it is inside of is the global one, here. The unusual, "bizarre" rule, which is independent of static scoping itself is, even when the definition is located inside another inner scope (it could only be a for statement or such), its containing scope is the global one. But with or without this rule, it's only about the location of the definition, not a call. I also think I might possibly understand why include leads you to similar expectations. include is done once when the definition of the procedure is seen, not when it is called. So that too, has nothing to do with the scope of the call. > ? JC > > -----Original Message----- > From: Rodney M. Bates [mailto:rbatesjk at lcwb.coop] > Sent: Friday, August 25, 2017 23:40 > To: reply+00655cb4faee270b469769c158f8bcd114e2942747144a0292cf0000000115b6154992a169ce0f0c9468 at reply.github.com; m3devel ; jcchu >> JC Chu > Subject: Re: [modula3/cm3] Quake scoping issue (#19) > > According to Quake, 7.3, "Procedures may be defined in the global scope only". > Apparently, from experiment, this means that, although the procedure definition > itself can be located inside a local scope, its name is declared in the global > scope. > > So, if you don't import libm3, your 'list' declaration is not a duplicate, thus > produces no error, and becomes declared in the global scope. But the call on > 'list' resolves to the formal parameter 'list', of 'map_proc', which is found > in the local scope, and whose value is the list '[ m3makefile2 ]', not a > procedure, and thus not callable. > > Any suitable renaming of either the parameter or the procedure, so that the two > meanings of 'list' have different names, works as expected. > > I'll grant that having a procedure declaration located in a local scope but > declaring its name in the global one is peculiar, and this is a peculiar > effect of that rule. > > I have made a note to explain this better in the Quake documentation. > > On 08/23/2017 11:17 PM, jcchu wrote: >> See demo.zip . >> >> ? >> You are receiving this because you are subscribed to this thread. >> Reply to this email directly, view it on GitHub , or mute the thread . >> > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Tue Aug 29 09:02:38 2017 From: jayk123 at hotmail.com (Jay K) Date: Tue, 29 Aug 2017 07:02:38 +0000 Subject: [M3devel] On the way to release other packages in GPL? In-Reply-To: References: <1323059193.3673624.1503775758492.ref@mail.yahoo.com> <1323059193.3673624.1503775758492@mail.yahoo.com> <20170827234046.GB31000@topoi.pooq.com> <8381B1BB-75DE-41D1-8DE1-65B788471E5D@purdue.edu> , Message-ID: 1. But I don't think he could sue w/o ownership. He could only encourage the owners to. 2. Static linking gcc makes everything in D:\dev2\cm3.1\m3-sys\m3cc\gcc\gcc\m3cg GPL -- at least when linked to gcc. But can't we dual license? The files/content I am interested in: m3-def.h I am the author of this. It is derived perhaps from some Modula-3 code. It is a funny file. It is C preprocessor and a long way toward our IR reading. And then m3cg.h -- this is machine generated. Not sure how that licensed in general. And then parse.c. Some large fraction of this is the IR reader and independent of gcc. And might be a good basis for other backends -- external backends written in C or C++ in particular. I haven't super much pushed on this because in principle, while I do like C and C++, I wrote the C backend in Modula-3 to try to really use this system, and writing/reading the IR is kinda well recognized as unnecessarily inefficient approach. It is used by m3cc as a license dodge, not for perhaps the best other engineering reasons. An LLVM system could use this approach, but could also generate LLVM IR in-proc, as I believe we have, or write the binary or textual "bitcode" -- again slower, but has advantages. However, I do have another idea. The M3CG IR could be the basis of a JIT or interpreter. They could be the distributed files. And that could be written in C or C++. And then these files become useful. It isn't clear however, when thinking about JIT, where to draw the lines in the pipeline -- how far to "lower" before redistributing. While we have this IR in hand, it isn't maybe stable enough long term. Unless the JIT was tightly bound to the IR somehow. We have changed it fairly regularly. We had no reason not to. - Jay ________________________________ From: Hosking, Antony L Sent: Monday, August 28, 2017 5:14 AM To: Jay K Cc: Hendrik Boom; m3devel at elegosoft.com Subject: Re: [M3devel] On the way to release other packages in GPL? On Aug 28, 2017, at 3:11 PM, Jay K > wrote: So, I think 1. Modula-3 maybe matters less these days? It is the precedent that mattered to him. He didn?t care about M3 either way. 2. It is the code owners that would have to object, right? I think, in principle, the way m3cg is built against gcc it must go under GPL. - Jay ________________________________ From: Hosking, Antony L > Sent: Sunday, August 27, 2017 10:06:46 PM To: Jay K Cc: Hendrik Boom; m3devel at elegosoft.com Subject: Re: [M3devel] On the way to release other packages in GPL? On Aug 28, 2017, at 10:18 AM, Jay K > wrote: Please no GPL. I want it all BSD, and one license for it all. Including the m3cg.h or such that I wrote that is currently GPL. I'll send mail on it later. Dual license might be required. This file in particular is C preprocessor code that helps read our IR. I'd also like to BSD parse.c but not clear we can. Try & see if anyone objects? Surely nobody will. RMS himself hit the roof when the original M3CG front-end to gcc was done, as he saw it as a threat to GPL. So, I wouldn?t count on that. - Jay ________________________________ From: M3devel > on behalf of Hendrik Boom > Sent: Sunday, August 27, 2017 4:40:46 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] On the way to release other packages in GPL? On Sat, Aug 26, 2017 at 07:29:18PM +0000, Daniel Alejandro Benavides D. wrote: > Hello:what if we ask to release all Modula-3 in GPL?https://www.dwheeler.com/misc/simplify-hp-release.txt > Thanks in advance You can release every package *you*write using the GPL. But you'll have licence compatibility issues because the majority of Modula 3 code is not covered by the GPL unless you also release it under a license compatible with the one that most of the Modula 3 stuff is licenced under. There's nothing difficult about having two licences. It just means there are two possible conditions under which someone can use and copy them. Its enough for either to apply, and it gets out of bothersome licence compatbility restrictions. -- hendrik _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: