From rodney.bates at wichita.edu Sun Mar 1 18:30:41 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 01 Mar 2009 11:30:41 -0600 Subject: [M3devel] aclocal.m4 Message-ID: <49AAC641.8050205@wichita.edu> What is the story on m3-sys/m3cc/gcc/mpfr/aclocal.m4? The cvs repository has a copy that is always empty and I always have a local copy with a lot of stuff in it, giving a lot of cvs diff output that makes it look like I made local changes. It this file always generated during the build process? Should it be removed from the repository? Rodney Bates From jay.krell at cornell.edu Sun Mar 1 20:31:56 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 1 Mar 2009 19:31:56 +0000 Subject: [M3devel] aclocal.m4 In-Reply-To: <49AAC641.8050205@wichita.edu> References: <49AAC641.8050205@wichita.edu> Message-ID: Probably you have auto* tools installed, and the timestamps are messed up somewhere, such that more stuff is being built. Similarly I used to always see the documentation get rebuilt in my builds, really fouling up cvs diff. I fixed that by having m3makefile say stuff like MAKEINFO=: (colon is an empty command). I never tracked down why the build steps were running which generally aren't supposed to, unless you edit files that "we" don't edit. Tangentially: gmp and mpfr are a significant fraction of building gcc. I wonder if we can't be smarter here..if /usr/local/lib/libgmp.a exists, tell configure not to build it, or somesuch. Back on topic. Most of you probably know this but just in case: In many projects in the wider Unixish/GNUish world, there are a lot of a certain class of checked in "derived" files. "Derived" being the Modula-3 term for "built" or "machine generated" or "compiler output", etc. "Derived" files are usually "binary", like .o files, but they can also be text files. For example, when you run configure it produces Makefile and config.h. The configure sh program is actually a "derived" file, from something like configure.ac. Makefile (not usually checked in) is derived from Makefile.in (usually checked in), which is often derived from Makefile.am. Now, further afield..from there are documentation-related checked in files, and the file you point out Rodney is probably generated. Another good example is people often checkin the output of lex or yacc, so that build who only have a C compiler/linker but not lex or yacc can build the software. Generally in source control the checked in derived files have a newer timestamp than their source files, so a build will "naturally" not try to build them. Often these files have "additional build dependencies" such as needing perl installed, that the project does not wish to foist upon everyone. So that's the background possibly all redundant. The questions boil down to: - What is up with the timestamps? I don't mean just on your machine Rodney. I generally don't have a full auto* toolset installed. I haven't figured out how is supposed to have a variety of versions installed /and/ have the Makefile pick the right one. I can all them all to separate -prefix, but that doesn't solve it. So, that implies why I don't see this exact case, but as I said, I used to see with this a bunch of other files. - You see it for other files too? - Other folks see it? - Is there a simple hack like I did for makeinfo that can quash it? I'll see. I guess I can just install latest autotools and see what happens. - Jay > Date: Sun, 1 Mar 2009 11:30:41 -0600 > From: rodney.bates at wichita.edu > To: m3devel at elegosoft.com > Subject: [M3devel] aclocal.m4 > > What is the story on m3-sys/m3cc/gcc/mpfr/aclocal.m4? The cvs repository has a > copy that is always empty and I always have a local copy with a lot of stuff > in it, giving a lot of cvs diff output that makes it look like I made local > changes. It this file always generated during the build process? Should it > be removed from the repository? > > Rodney Bates -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 2 14:30:22 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Mar 2009 13:30:22 +0000 Subject: [M3devel] aclocal.m4 In-Reply-To: <49AAC641.8050205@wichita.edu> References: <49AAC641.8050205@wichita.edu> Message-ID: This appears to be fixed in mpfr 2.3.2. We have 2.3.0. I didn't look at 2.3.1 or track down when the fix came in. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rodney.bates at wichita.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] aclocal.m4 > Date: Mon, 2 Mar 2009 13:25:38 +0000 > > > "This stuff" is mostly disabled by lack of -enable-maintainer-mode > on the configure command line. > In most of the Makefiles there is @MAINT@ which by default evaluates to a comment. > Mpfr doesn't do it this way. > Maybe due to different versions of auto tools? > That's what I know so far.. > > - Jay > > ________________________________ >> From: jay.krell at cornell.edu >> To: rodney.bates at wichita.edu; m3devel at elegosoft.com >> Subject: RE: [M3devel] aclocal.m4 >> Date: Sun, 1 Mar 2009 19:31:56 +0000 >> >> >> >> >> >> >> >> >> Probably you have auto* tools installed, and the timestamps are messed up somewhere, such that more stuff is being built. Similarly I used to always see the documentation get rebuilt in my builds, really fouling up cvs diff. I fixed that by having m3makefile say stuff like MAKEINFO=: (colon is an empty command). I never tracked down why the build steps were running which generally aren't supposed to, unless you edit files that "we" don't edit. >> >> >> >> >> >> Tangentially: gmp and mpfr are a significant fraction of building gcc. I wonder if we can't be smarter here..if /usr/local/lib/libgmp.a exists, tell configure not to build it, or somesuch. >> >> >> >> Back on topic. Most of you probably know this but just in case: >> >> In many projects in the wider Unixish/GNUish world, there are a lot of a certain class of checked in "derived" files. "Derived" being the Modula-3 term for "built" or "machine generated" or "compiler output", etc. "Derived" files are usually "binary", like .o files, but they can also be text files. For example, when you run configure it produces Makefile and config.h. >> >> The configure sh program is actually a "derived" file, from something like configure.ac. >> >> Makefile (not usually checked in) is derived from Makefile.in (usually checked in), which is often derived from Makefile.am. >> >> Now, further afield..from there are documentation-related checked in files, and the file you point out Rodney is probably generated. >> >> Another good example is people often checkin the output of lex or yacc, so that build who only have a C compiler/linker but not lex or yacc can build the software. >> >> >> >> Generally in source control the checked in derived files have a newer timestamp than their source files, so a build will "naturally" not try to build them. >> >> Often these files have "additional build dependencies" such as needing perl installed, that the project does not wish to foist upon everyone. >> >> >> >> So that's the background possibly all redundant. >> >> >> >> The questions boil down to: >> >> - What is up with the timestamps? >> >> I don't mean just on your machine Rodney. I generally don't have a full auto* toolset installed. I haven't figured out how is supposed to have a variety of versions installed /and/ have the Makefile pick the right one. I can all them all to separate -prefix, but that doesn't solve it. >> >> So, that implies why I don't see this exact case, but as I said, I used to see with this a bunch of other files. >> >> >> >> - You see it for other files too? >> >> >> >> - Other folks see it? >> >> >> >> - Is there a simple hack like I did for makeinfo that can quash it? I'll see. >> >> >> >> I guess I can just install latest autotools and see what happens. >> >> >> >> >> >> - Jay >> >> >> >>> Date: Sun, 1 Mar 2009 11:30:41 -0600 >>> From: rodney.bates at wichita.edu >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] aclocal.m4 >>> >>> What is the story on m3-sys/m3cc/gcc/mpfr/aclocal.m4? The cvs repository has a >>> copy that is always empty and I always have a local copy with a lot of stuff >>> in it, giving a lot of cvs diff output that makes it look like I made local >>> changes. It this file always generated during the build process? Should it >>> be removed from the repository? >>> >>> Rodney Bates From jay.krell at cornell.edu Mon Mar 2 14:25:38 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Mar 2009 13:25:38 +0000 Subject: [M3devel] aclocal.m4 In-Reply-To: <49AAC641.8050205@wichita.edu> References: <49AAC641.8050205@wichita.edu> Message-ID: "This stuff" is mostly disabled by lack of -enable-maintainer-mode on the configure command line. In most of the Makefiles there is @MAINT@ which by default evaluates to a comment. Mpfr doesn't do it this way. Maybe due to different versions of auto tools? That's what I know so far.. - Jay ________________________________ > From: jay.krell at cornell.edu > To: rodney.bates at wichita.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] aclocal.m4 > Date: Sun, 1 Mar 2009 19:31:56 +0000 > > > > > > > > > Probably you have auto* tools installed, and the timestamps are messed up somewhere, such that more stuff is being built. Similarly I used to always see the documentation get rebuilt in my builds, really fouling up cvs diff. I fixed that by having m3makefile say stuff like MAKEINFO=: (colon is an empty command). I never tracked down why the build steps were running which generally aren't supposed to, unless you edit files that "we" don't edit. > > > > > > Tangentially: gmp and mpfr are a significant fraction of building gcc. I wonder if we can't be smarter here..if /usr/local/lib/libgmp.a exists, tell configure not to build it, or somesuch. > > > > Back on topic. Most of you probably know this but just in case: > > In many projects in the wider Unixish/GNUish world, there are a lot of a certain class of checked in "derived" files. "Derived" being the Modula-3 term for "built" or "machine generated" or "compiler output", etc. "Derived" files are usually "binary", like .o files, but they can also be text files. For example, when you run configure it produces Makefile and config.h. > > The configure sh program is actually a "derived" file, from something like configure.ac. > > Makefile (not usually checked in) is derived from Makefile.in (usually checked in), which is often derived from Makefile.am. > > Now, further afield..from there are documentation-related checked in files, and the file you point out Rodney is probably generated. > > Another good example is people often checkin the output of lex or yacc, so that build who only have a C compiler/linker but not lex or yacc can build the software. > > > > Generally in source control the checked in derived files have a newer timestamp than their source files, so a build will "naturally" not try to build them. > > Often these files have "additional build dependencies" such as needing perl installed, that the project does not wish to foist upon everyone. > > > > So that's the background possibly all redundant. > > > > The questions boil down to: > > - What is up with the timestamps? > > I don't mean just on your machine Rodney. I generally don't have a full auto* toolset installed. I haven't figured out how is supposed to have a variety of versions installed /and/ have the Makefile pick the right one. I can all them all to separate -prefix, but that doesn't solve it. > > So, that implies why I don't see this exact case, but as I said, I used to see with this a bunch of other files. > > > > - You see it for other files too? > > > > - Other folks see it? > > > > - Is there a simple hack like I did for makeinfo that can quash it? I'll see. > > > > I guess I can just install latest autotools and see what happens. > > > > > > - Jay > > > >> Date: Sun, 1 Mar 2009 11:30:41 -0600 >> From: rodney.bates at wichita.edu >> To: m3devel at elegosoft.com >> Subject: [M3devel] aclocal.m4 >> >> What is the story on m3-sys/m3cc/gcc/mpfr/aclocal.m4? The cvs repository has a >> copy that is always empty and I always have a local copy with a lot of stuff >> in it, giving a lot of cvs diff output that makes it look like I made local >> changes. It this file always generated during the build process? Should it >> be removed from the repository? >> >> Rodney Bates From jay.krell at cornell.edu Mon Mar 2 16:48:44 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Mar 2009 15:48:44 +0000 Subject: [M3devel] PA32_HPUX available Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-PA32_HPUX-1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-PA32_HPUX-1.tar.lzma Here is a current build of PA32_HPUX, including all of "std". The system builds itself and various gui apps startup. Pthreads are used. User threads are not implemented. The man page for get/set/make/swapcontext says they won't necessarily stay compatible. Dynamic linking is supported and used. This should match the current source tree, except my change to cm3cfg.common isn't reflected here -- the backend is not itself optimized. It requires the GNU C compiler and assembler -- gcc and gas. It does not require, and probably won't work with, the GNU linker. e.g. extract binutils and then rm -rf intl gold ld elfcpp binutils, leaving just like libiberaty, bfd, opcodes, gas, and then build it, or use -disable-x to not build those directories, or build it all, but instead of install, just copy gas, it's just one file. It might require getting up to date patches esp. for ld. I was not able to build libstdc++ without patching ld, but building libstdc++ is not necessary for Modula-3. It is a C++ thing. I'm using HP-UX 11iv1 aka 11.11 (this is two versions out of date, there is v2 and v3). The cm3.cfg file in the archive delegates to $CM3_ROOT/m3-sys/cminstall/src/config-no-install/PA32_HPUX. and that file is somewhat specific to my configuration. I can see about making it just use $PATH. Problem is, on this sytem gcc doesn't support multilibs/-m32/-m64, so you really need two separate "prefixes" and paths to work with 32bit and 64bit targets, so I use /usr/local/32 and /usr/local/64. It is possible to bootstrap to a good working system from the bundled compiler, but you have to go through gcc 3.3.6 first. There are my full paths in these binaries: /cm3/lib/libm3core.sl.5 and such but you can set SHLIB_PATH to a colon delimited directory that includes where you install to. I haven't figured out yet how to omit the paths. Perhaps we should use "$ORIGIN/../lib"? Also, the stock HP-UX system does contain X or OpenGL headers/libs, but they are a free download. Search the web. At least the X headers/libs come with the unbundled compiler. mentor does not work. It says: "*** Cannot create TCP port". If $DISPLAY is not set correctly, the errors are not consistent. - Jay From jay.krell at cornell.edu Mon Mar 2 21:37:48 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Mar 2009 20:37:48 +0000 Subject: [M3devel] -g other than -gstabs? Message-ID: Has anyone looked into why -g, -ggdb, -gwhateverelse tend to crash m3cgc1? While -gstabs and -gstabs+ work ok? -gstabs isn't supported on hppa64-hpux. I'll try to look into this, if nobody else has the answer. The double thing isn't fully resolved either, as hppa64-hpux hangs in TimePosix too. I'll patch parse.c inappropriately locally for now and look into it more "later". (Even without -g the stack is shown, so I can see TimePosix hang.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Mar 2 23:13:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 02 Mar 2009 23:13:44 +0100 Subject: [M3devel] cm3 tinderbox status Message-ID: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> Being back in town, I find that over the weekend almost all of the m3 tests in tinderbox failed. What's going on there? I don't want to sound like Kassandra, especially since I'm not contributing actively myself currently, but I'd really like all committers to keep an eye on all the regression tests and fix things as soon as they fall off in quality. I've got the slight feeling that the overall quality of the M3 code base does not really increase currently. Please, let's all try to keep everything working as good as possible. If you check in something, monitor the effects in the various tinderbox regressions tests: http://tinderbox.elegosoft.com/tinderbox/cm3/status.html http://www.opencm3.net/logs/package-status.html http://www.opencm3.net/m3tests/index.html Thanks in advance for your cooperation and help, Olaf PS: I also have the strong feeling that an official release is overdue. We should stop developing features and focus on building stable new distribution archives for a while. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Mar 2 23:52:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Mar 2009 09:52:50 +1100 Subject: [M3devel] cm3 tinderbox status In-Reply-To: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> References: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> Message-ID: Hear hear. Things have been broken for days now... On 3 Mar 2009, at 09:13, Olaf Wagner wrote: > Being back in town, I find that over the weekend almost all of the > m3 tests in tinderbox failed. What's going on there? > > I don't want to sound like Kassandra, especially since I'm not > contributing actively myself currently, but I'd really like > all committers to keep an eye on all the regression tests and > fix things as soon as they fall off in quality. I've got the > slight feeling that the overall quality of the M3 code base > does not really increase currently. > > Please, let's all try to keep everything working as good as possible. > If you check in something, monitor the effects in the various > tinderbox regressions tests: > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > http://www.opencm3.net/logs/package-status.html > http://www.opencm3.net/m3tests/index.html > > Thanks in advance for your cooperation and help, > > Olaf > > PS: I also have the strong feeling that an official release is > overdue. We should stop developing features and focus on building > stable new distribution archives for a while. > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Tue Mar 3 00:56:46 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Mar 2009 23:56:46 +0000 Subject: [M3devel] cm3 tinderbox status In-Reply-To: References: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> Message-ID: I checked the status page, but there was no red. I see the large numbers now. Lots of +"/home/m3/work/cm3-ws/birch.elegosoft.com-2009-03-02-15-00-03/cm3/m3-sys/m3tests/src/Test.i3", line 8: unable to find interface (Usysdep) That's me. Sorry. I'll get to it tonight. In the meantime, feel free to roll it back. - Jay > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 3 Mar 2009 09:52:50 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 tinderbox status > > Hear hear. Things have been broken for days now... > > On 3 Mar 2009, at 09:13, Olaf Wagner wrote: > > > Being back in town, I find that over the weekend almost all of the > > m3 tests in tinderbox failed. What's going on there? > > > > I don't want to sound like Kassandra, especially since I'm not > > contributing actively myself currently, but I'd really like > > all committers to keep an eye on all the regression tests and > > fix things as soon as they fall off in quality. I've got the > > slight feeling that the overall quality of the M3 code base > > does not really increase currently. > > > > Please, let's all try to keep everything working as good as possible. > > If you check in something, monitor the effects in the various > > tinderbox regressions tests: > > > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > > http://www.opencm3.net/logs/package-status.html > > http://www.opencm3.net/m3tests/index.html > > > > Thanks in advance for your cooperation and help, > > > > Olaf > > > > PS: I also have the strong feeling that an official release is > > overdue. We should stop developing features and focus on building > > stable new distribution archives for a while. > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 3 01:02:05 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 3 Mar 2009 00:02:05 +0000 Subject: [M3devel] cm3 tinderbox status In-Reply-To: References: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> Message-ID: > In the meantime, feel free to roll it back. It being the test code that I added, changes only in m3-sys/m3tests. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] cm3 tinderbox status Date: Mon, 2 Mar 2009 23:56:46 +0000 I checked the status page, but there was no red. I see the large numbers now. Lots of +"/home/m3/work/cm3-ws/birch.elegosoft.com-2009-03-02-15-00-03/cm3/m3-sys/m3tests/src/Test.i3", line 8: unable to find interface (Usysdep) That's me. Sorry. I'll get to it tonight. In the meantime, feel free to roll it back. - Jay > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 3 Mar 2009 09:52:50 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 tinderbox status > > Hear hear. Things have been broken for days now... > > On 3 Mar 2009, at 09:13, Olaf Wagner wrote: > > > Being back in town, I find that over the weekend almost all of the > > m3 tests in tinderbox failed. What's going on there? > > > > I don't want to sound like Kassandra, especially since I'm not > > contributing actively myself currently, but I'd really like > > all committers to keep an eye on all the regression tests and > > fix things as soon as they fall off in quality. I've got the > > slight feeling that the overall quality of the M3 code base > > does not really increase currently. > > > > Please, let's all try to keep everything working as good as possible. > > If you check in something, monitor the effects in the various > > tinderbox regressions tests: > > > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > > http://www.opencm3.net/logs/package-status.html > > http://www.opencm3.net/m3tests/index.html > > > > Thanks in advance for your cooperation and help, > > > > Olaf > > > > PS: I also have the strong feeling that an official release is > > overdue. We should stop developing features and focus on building > > stable new distribution archives for a while. > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Mar 3 01:18:27 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Mar 2009 11:18:27 +1100 Subject: [M3devel] cm3 tinderbox status In-Reply-To: References: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> Message-ID: Looks like you introduced a dependence on Usysdep.i3 which is not present on all platforms. On 3 Mar 2009, at 10:56, Jay wrote: > I checked the status page, but there was no red. I see the large > numbers now. > > Lots of > +"/home/m3/work/cm3-ws/birch.elegosoft.com-2009-03-02-15-00-03/cm3/ > m3-sys/m3tests/src/Test.i3", line 8: unable to find interface > (Usysdep) > > That's me. Sorry. > I'll get to it tonight. > In the meantime, feel free to roll it back. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: wagner at elegosoft.com > > Date: Tue, 3 Mar 2009 09:52:50 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] cm3 tinderbox status > > > > Hear hear. Things have been broken for days now... > > > > On 3 Mar 2009, at 09:13, Olaf Wagner wrote: > > > > > Being back in town, I find that over the weekend almost all of the > > > m3 tests in tinderbox failed. What's going on there? > > > > > > I don't want to sound like Kassandra, especially since I'm not > > > contributing actively myself currently, but I'd really like > > > all committers to keep an eye on all the regression tests and > > > fix things as soon as they fall off in quality. I've got the > > > slight feeling that the overall quality of the M3 code base > > > does not really increase currently. > > > > > > Please, let's all try to keep everything working as good as > possible. > > > If you check in something, monitor the effects in the various > > > tinderbox regressions tests: > > > > > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > > > http://www.opencm3.net/logs/package-status.html > > > http://www.opencm3.net/m3tests/index.html > > > > > > Thanks in advance for your cooperation and help, > > > > > > Olaf > > > > > > PS: I also have the strong feeling that an official release is > > > overdue. We should stop developing features and focus on building > > > stable new distribution archives for a while. > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > > Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > > 45 86 95 > > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > > Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > > DE163214194 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 3 01:33:44 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 3 Mar 2009 00:33:44 +0000 Subject: [M3devel] cm3 tinderbox status In-Reply-To: References: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> Message-ID: Oops, right, I added it, oops, right it might not be on all platforms. I think we can trivially add it on all platforms with a small change in m3core/src/unix/common/m3makefile, even if it isn't otherwise used (yet), though it'll have to be present, and correct for the test to work, which it likely is. I realize it's not very valuable to use something /only/ in a test, but I hope to have it get more use, once user threading is implemented along with it. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 3 Mar 2009 11:18:27 +1100 CC: m3devel at elegosoft.com Subject: Re: [M3devel] cm3 tinderbox status Looks like you introduced a dependence on Usysdep.i3 which is not present on all platforms. On 3 Mar 2009, at 10:56, Jay wrote: I checked the status page, but there was no red. I see the large numbers now. Lots of +"/home/m3/work/cm3-ws/birch.elegosoft.com-2009-03-02-15-00-03/cm3/m3-sys/m3tests/src/Test.i3", line 8: unable to find interface (Usysdep) That's me. Sorry. I'll get to it tonight. In the meantime, feel free to roll it back. - Jay > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 3 Mar 2009 09:52:50 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 tinderbox status > > Hear hear. Things have been broken for days now... > > On 3 Mar 2009, at 09:13, Olaf Wagner wrote: > > > Being back in town, I find that over the weekend almost all of the > > m3 tests in tinderbox failed. What's going on there? > > > > I don't want to sound like Kassandra, especially since I'm not > > contributing actively myself currently, but I'd really like > > all committers to keep an eye on all the regression tests and > > fix things as soon as they fall off in quality. I've got the > > slight feeling that the overall quality of the M3 code base > > does not really increase currently. > > > > Please, let's all try to keep everything working as good as possible. > > If you check in something, monitor the effects in the various > > tinderbox regressions tests: > > > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > > http://www.opencm3.net/logs/package-status.html > > http://www.opencm3.net/m3tests/index.html > > > > Thanks in advance for your cooperation and help, > > > > Olaf > > > > PS: I also have the strong feeling that an official release is > > overdue. We should stop developing features and focus on building > > stable new distribution archives for a while. > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rv82 at ya.ru Thu Mar 5 03:33:00 2009 From: rv82 at ya.ru (=?KOI8-R?B?98/Sz87P1yDyz83Bzg==?=) Date: Thu, 05 Mar 2009 05:33:00 +0300 Subject: [M3devel] Building DLLs for Win32 (NT386MINGNU) Message-ID: <291431236220380@webmail61.yandex.ru> Hello! Tell me please, how to build DLL in Win32 for using it with non Modula-3's programs? I use NT386MINGNU version of cm3. From jay.krell at cornell.edu Thu Mar 5 04:29:59 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 5 Mar 2009 03:29:59 +0000 Subject: [M3devel] Building DLLs for Win32 (NT386MINGNU) In-Reply-To: <291431236220380@webmail61.yandex.ru> References: <291431236220380@webmail61.yandex.ru> Message-ID: I think that is currently problematic. In particular, I don't think the Modula-3 runtime -- threading and garbage collection -- likes to be called on threads that were not created with it. I am also not sure that module initializers will get called if "main" is not written in Modula-3. Again, I'm not sure. I think I know how to mostly fix both of these problems, if they indeed both exist, though I think in general module initializers, like C++ static constructors, are problematic and cannot be implemented well. Modula-3 may be less problematic in a few ways -- in that the ordering is apparently guaranteed well defined or at least not circular, and, well, we may not have a legacy of calling them from DllMain, which is good and bad. DllMain is called with a lock held, giving you "free" serialization. However that also means you can't do much, without risk of deadlock, or of increasing contention (slowness) on that lock. A hybrid model might be viable, where if "main" is written in Modula-3, the initializers are all run early in main, outside the lock, but if "main" is not written in Modula-3, call the initializers from DllMain. In particular, one easy hack that comes to mind, is module initializers could see if the process's executable imports m3core.dll. If so, assume they will be called, else, not. Similar but less code is to export something from Modula-3 executables, a dummy marker, IAmWrittenWithModula3(), have the module initializers GetProcAddress and if it is not null.. (possibly something more general/extensible for the executable to "advertsize" arbitrary "properties" about itself). Initializers are also problematic because they often front load stuff unnecessarily -- do variables really all have to be initialized when the module loads, or only upon first use? Granted, doing it on first use implies an overhead for every use. But doing at load time implies a possibly unnecessary overhead for loading. But also, folks that do try on-demand initialization often get it wrong (i.e. not thread safe) -- I've fixed several examples around the Modula-3 tree, and I don't have a way to systematically find them, I just happen upon them. Cygwin has serious problems here too -- "main" not in something written using cygwin, leads to cygwin1.dll not being initialized easily/properly, and they seem to consider it not a problem. Some folks seem to have in mind relatively monolithic apps, all written using the same toolset and using the same runtime, while in reality many many apps are dynamically composed at load-time or run-time from separately authored pieces, "plugins" and such. The best example I have found here, of a simple application, that people might think is monolithic -- all dependencies known at build time or initial launch -- but is not actually monolithic -- is notepad. If you print from notepad, printer driver ui is dynamically loaded (indirectly) by it. Apart from Modula-3 and Cygwin1.dll, most .dlls handle their own initialization in their DllMain, and do not depend on their client to initialize them. The main counterexample is ole32.dll and its CoInitialize, which I think is kind of broken. Btw, this all meant to apply to NT386 and NT386MINGNU. They follow the same basic model. I'll look into this further, later. (see also: how do I catch a Modula-3 exception in C++, or a C++ exception in Modula-3? Answer: Don't/can't. Heck, there is no interop even from one C++ implementation to another..) - Jay > From: rv82 at ya.ru > To: m3devel at elegosoft.com > Date: Thu, 5 Mar 2009 05:33:00 +0300 > Subject: [M3devel] Building DLLs for Win32 (NT386MINGNU) > > Hello! > Tell me please, how to build DLL in Win32 for using it with non Modula-3's programs? I use NT386MINGNU version of cm3. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 5 16:52:46 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 5 Mar 2009 15:52:46 +0000 Subject: [M3devel] Building DLLs for Win32 (NT386MINGNU) In-Reply-To: <410661236228256@webmail2.yandex.ru> References: <291431236220380@webmail61.yandex.ru> <410661236228256@webmail2.yandex.ru> Message-ID: > From: rv82 at ya.ru > To: jay.krell at cornell.edu > Subject: Re: [M3devel] Building DLLs for Win32 (NT386MINGNU) > Date: Thu, 5 Mar 2009 07:44:16 +0300 > > And, Is it possible to use DLLs built with other languages? For example, > may I import DLL built by C in Modula-3 program? Definitely..just perhaps not stuff built with Cygwin (nothing to do with Modula-3, interop with Cygwin is slightly difficult even for C code built with another compiler/runtime). Basically, you have to rewrite your headers in Modula-3. Modula-3 "headers" are ".i3" files -- i for interface, 3 for Modula-3. And either LoadLibrary/GetProcAddress, or have an import .lib. In the Modula-3 you mark the functions with an "external" "pragma". Large example: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/win32/WinBase.i3?rev=1.7;content-type=text%2Fplain small example.. There were some nice small examples in the Critical Mass product. I can't find them online. Maybe... http://modula3.elegosoft.com/cm3/doc/index.html has a link "CM3 Examples" to http://modula3.elegosoft.com/cm3/doc/example/ but it doesn't work. I know this is kind of difficult to understand..but think about this..the Modula-3 compiler and runtime are written in Modula-3. They work. They read and write files, create threads, etc. -- they use the underlying system, which is composed of .dlls, which aren't written in Modula-3. Therefore, the answer to your question must be "yes". They call into the underlying system from Modula-3 using the same techniques as you would use. Of course, you also want to know how to do it, which this thought exercise does not immediately reveal -- you'd have to look at the compiler/runtime, find the calls to open files, etc., and trace them down. You would in fact eventually get to this WinBase.i3 file and its CreateFile declaration, but it takes searching through a few layers. Another thing you can do is run the compiler under a debugger and break on CreateFile (CreateFileA, CreateFileW) and look at the stack, and the file names on it. That can speed the search significantly. Oh, and WinBase.i3 wouldn't be on the stack, as the way it works, these declarations let other Modula-3 code call directly into the underlying system, without a "wrapper". (Well, lately I have been adding wrappers, for a good reason, but that is another matter.) Um, why do you favor NT386MINGNU/mingw over NT386/Visual C++? There is a free "beer" download, the "Express Edition", which should work. Have you tried that? I know there are reasons but I'm curious to know what yours are. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Mar 6 05:54:55 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 05 Mar 2009 23:54:55 -0500 Subject: [M3devel] Building DLLs for Win32 (NT386MINGNU) Message-ID: <49B0664F020000D7000537ED@scires.com> I'm reposting this because something went wrong when I tried sending earlier. This version has more complete info. --RCC >>> Jay 03/05/09 11:25 AM >>> .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:Verdana } ... There were some nice small examples in the Critical Mass product. I can't find them online. ... Jay, I checked in the examples folder back when I added the CM3IDE package. Indeed, if you use CM3IDE, it has a link directly to the examples index and it will let you build and run each example. You have to put the examples folder into your cm3 file tree as described in cm3/examples/README. This folder is in the repository! Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Mar 7 23:27:47 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 7 Mar 2009 22:27:47 +0000 Subject: [M3devel] PA32_HPUX available Message-ID: I have replaced these with: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-PA32_HPUX-d5.7.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-PA32_HPUX-d5.7.1.tar.lzma http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-PA32_HPUX-d5.7.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-PA32_HPUX-d5.7.1.tar.lzma These are "completely rebuilt", not just "repackaged". and also made sure that all the non-NT386 platforms have .tar.gz and .tar.lzma, and no .tar.bz2. Roughly/statistically speaking: .lzma is "always" much smaller than .gz, doesn't take too much longer to decompress, takes much longer to compress. .bz2 is "always" in between in size, and takes the longest to compress and decompress. lzma is the least widely deployed, gzip is the most widely deployed, bzip2 is somewhere in between. lzma is written in C++, which may negatively impact one's ability to build it. - Jay > From: jay.krell@ > To: m3devel@ > Subject: PA32_HPUX available > Date: Mon, 2 Mar 2009 15:48:44 +0000 > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-PA32_HPUX-1.tar.gz > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-PA32_HPUX-1.tar.lzma > > > Here is a current build of PA32_HPUX, including all of "std". > > > The system builds itself and various gui apps startup. > Pthreads are used. User threads are not implemented. > The man page for get/set/make/swapcontext says they won't necessarily stay compatible. > > > Dynamic linking is supported and used. > > > This should match the current source tree, except my change to cm3cfg.common > isn't reflected here -- the backend is not itself optimized. > > > It requires the GNU C compiler and assembler -- gcc and gas. > > > It does not require, and probably won't work with, the GNU linker. > e.g. extract binutils and then rm -rf intl gold ld elfcpp binutils, > leaving just like libiberaty, bfd, opcodes, gas, > and then build it, or use -disable-x to not build those directories, > or build it all, but instead of install, just copy gas, it's just one file. > > > It might require getting up to date patches esp. for ld. > I was not able to build libstdc++ without patching ld, but > building libstdc++ is not necessary for Modula-3. It is a C++ thing. > > > I'm using HP-UX 11iv1 aka 11.11 (this is two versions out of date, > there is v2 and v3). > > > The cm3.cfg file in the archive delegates to > $CM3_ROOT/m3-sys/cminstall/src/config-no-install/PA32_HPUX. > and that file is somewhat specific to my configuration. > I can see about making it just use $PATH. > Problem is, on this sytem gcc doesn't support multilibs/-m32/-m64, > so you really need two separate "prefixes" and paths to work with > 32bit and 64bit targets, so I use /usr/local/32 and /usr/local/64. > > > It is possible to bootstrap to a good working system from > the bundled compiler, but you have to go through gcc 3.3.6 first. > > > There are my full paths in these binaries: > /cm3/lib/libm3core.sl.5 and such > > but you can set SHLIB_PATH to a colon delimited directory > that includes where you install to. > > > I haven't figured out yet how to omit the paths. > Perhaps we should use "$ORIGIN/../lib"? > > > Also, the stock HP-UX system does contain X or OpenGL headers/libs, > but they are a free download. Search the web. > At least the X headers/libs come with the unbundled compiler. > > mentor does not work. > It says: "*** Cannot create TCP port". > If $DISPLAY is not set correctly, the errors are not consistent. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 9 08:21:25 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 9 Mar 2009 07:21:25 +0000 Subject: [M3devel] subsecond resolution on file times? Message-ID: eh? We've got sub-second resolution, why not keep it? C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FSPosix.m3 PROCEDURE SetModificationTime(pn: Pathname.T; READONLY t: Time.T) RAISES {OSError.E}= CONST Accessed = 0; Updated = 1; VAR u: ARRAY [Accessed .. Updated] OF Utime.struct_timeval; fname := M3toC.SharedTtoS(pn); BEGIN u[Updated].tv_sec := ROUND(t); u[Updated].tv_usec := 0; u[Accessed].tv_sec := ROUND(Time.Now()); u[Accessed].tv_usec := 0; IF Unix.utimes(fname, ADR(u)) < 0 THEN Fail(pn, fname); END; M3toC.FreeSharedS(pn, fname); END SetModificationTime; http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html "The times in the timeval structure are measured in seconds and microseconds since the Epoch, although rounding toward the nearest second may occur." Rounding may occur, but won't necessarily. Are there systems that fail if tv_usec != 0? This is what TimePosix.ToUtime is for, eh? I was looking to see if I could remove Usysdep.struct_timeval, as part of reducing/eliminating Usysdep. The opengroup link says to use utime() instead of utimes() for portability? True? I'm skeptical. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Tue Mar 10 01:37:11 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Mon, 09 Mar 2009 19:37:11 -0500 Subject: [M3devel] Trestle question Message-ID: <49B5B637.3050702@bellsouth.net> Does CM3 support Trestle? I was trying some code from the Trestle Tutorial (DEC SRC Memo 69) but CM3 says it can't find TextVBT or Trestle. If it is still supported, is there a guide to how CM3 implements/uses it? From jay.krell at cornell.edu Tue Mar 10 01:51:58 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 10 Mar 2009 00:51:58 +0000 Subject: [M3devel] Trestle question In-Reply-To: <49B5B637.3050702@bellsouth.net> References: <49B5B637.3050702@bellsouth.net> Message-ID: It's definitely there and it should be about the same as it ever was. If you start with a "min" distribution, you need to built it yourself. If you start with "std", it should just be in there. - Jay > Date: Mon, 9 Mar 2009 19:37:11 -0500 > From: martinbishop at bellsouth.net > To: m3devel at elegosoft.com > Subject: [M3devel] Trestle question > > Does CM3 support Trestle? I was trying some code from the Trestle > Tutorial (DEC SRC Memo 69) but CM3 says it can't find TextVBT or Trestle. > > If it is still supported, is there a guide to how CM3 implements/uses it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 10 02:11:40 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 10 Mar 2009 01:11:40 +0000 Subject: [M3devel] Trestle question In-Reply-To: References: <49B5B637.3050702@bellsouth.net> Message-ID: Oh, maybe you need import() or something like that in your m3makefile? You probably do, but again, same as it mostly ever was. Poke around in the tree for gui apps like showthread, juno, etc., look at their m3makefiles. - Jay > From: martinbishop@ > To: m3devel@ > Subject: [M3devel] Trestle question > > Does CM3 support Trestle? -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Tue Mar 10 02:24:32 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Mon, 09 Mar 2009 20:24:32 -0500 Subject: [M3devel] Trestle question In-Reply-To: References: <49B5B637.3050702@bellsouth.net> Message-ID: <49B5C150.2000102@bellsouth.net> Jay wrote: > Oh, maybe you need import() or something like that in your m3makefile? > > You probably do, but again, same as it mostly ever was. > > Poke around in the tree for gui apps like showthread, juno, etc., > > look at their m3makefiles. > > > > - Jay > >> From: martinbishop@ >> To: m3devel@ >> Subject: [M3devel] Trestle question >> >> Does CM3 support Trestle? > Yeah, I wasn't used to using m3makefiles (just did 'cm3' in the directory). Anyway, I got it working, and am pleased with Trestle :) From wagner at elegosoft.com Wed Mar 11 11:39:43 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 11 Mar 2009 11:39:43 +0100 Subject: [M3devel] subsecond resolution on file times? In-Reply-To: References: Message-ID: <20090311113943.tyun2cpps0o8s4w0@mail.elegosoft.com> Quoting Jay : > > eh? We've got sub-second resolution, why not keep it? Offhand I don't see any reason to hide fine grained resolutions if the system supports them. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From martinbishop at bellsouth.net Fri Mar 13 18:55:42 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Fri, 13 Mar 2009 12:55:42 -0500 Subject: [M3devel] Classic Modula-3 Books Message-ID: <49BA9E1E.4090606@bellsouth.net> Is there any chance that "classic" books on Modula-3 like "Modula-3" by Harbison (I own a copy, it's a great book) or "Systems Programming With Modula-3" by Nelson might one day be released online? They aren't in print anymore, and I can't imagine there is much demand for them...I found "Modula-3" used for $1 on Amazon, but "Systems Programming With Modula-3" is $40 at it's cheapest, used :( From martinbishop at bellsouth.net Sat Mar 14 08:22:31 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Sat, 14 Mar 2009 02:22:31 -0500 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <200903140704.n2E74S3i079116@camembert.async.caltech.edu> References: <200903140704.n2E74S3i079116@camembert.async.caltech.edu> Message-ID: <49BB5B37.5000907@bellsouth.net> Where is Nelson's book available? I don't think I ever saw it? Unless you mean in DEC memos or something? Mika Nystrom wrote: > Hi Martin, > > I once emailed the publisher about permission to reproduce parts of > these books for a class I was teaching, and all I got was silence. > > Harbison's book was listed as a "print on demand" book for a while, > if I remember right. Most of Nelson's book is already available > online (which chapters are not?), albeit in a less organized way. > > Last time I bought Nelson, I found it cheaper at amazon.co.uk, > and they had several copies for < $10. Try www.addall.com or a > similar search engine... > > Mika > > Martin Bishop writes: >> Is there any chance that "classic" books on Modula-3 like "Modula-3" by >> Harbison (I own a copy, it's a great book) or "Systems Programming With >> Modula-3" by Nelson might one day be released online? >> >> They aren't in print anymore, and I can't imagine there is much demand >> for them...I found "Modula-3" used for $1 on Amazon, but "Systems >> Programming With Modula-3" is $40 at it's cheapest, used :( > From mika at async.caltech.edu Sat Mar 14 11:55:02 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 14 Mar 2009 03:55:02 -0700 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: Your message of "Sat, 14 Mar 2009 02:22:31 CDT." <49BB5B37.5000907@bellsouth.net> Message-ID: <200903141055.n2EAt2IS087290@camembert.async.caltech.edu> Right, most (if not all) of the chapters are available as SRC research reports. I find the book very convenient so I have three or four copies of it, but if you don't want to spend the money I think you can assemble it yourself. Mika Martin Bishop writes: >Where is Nelson's book available? I don't think I ever saw it? Unless >you mean in DEC memos or something? > >Mika Nystrom wrote: >> Hi Martin, >> >> I once emailed the publisher about permission to reproduce parts of >> these books for a class I was teaching, and all I got was silence. >> >> Harbison's book was listed as a "print on demand" book for a while, >> if I remember right. Most of Nelson's book is already available >> online (which chapters are not?), albeit in a less organized way. >> >> Last time I bought Nelson, I found it cheaper at amazon.co.uk, >> and they had several copies for < $10. Try www.addall.com or a >> similar search engine... >> >> Mika >> >> Martin Bishop writes: >>> Is there any chance that "classic" books on Modula-3 like "Modula-3" by >>> Harbison (I own a copy, it's a great book) or "Systems Programming With >>> Modula-3" by Nelson might one day be released online? >>> >>> They aren't in print anymore, and I can't imagine there is much demand >>> for them...I found "Modula-3" used for $1 on Amazon, but "Systems >>> Programming With Modula-3" is $40 at it's cheapest, used :( >> From hendrik at topoi.pooq.com Fri Mar 13 21:23:59 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 13 Mar 2009 16:23:59 -0400 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <49BA9E1E.4090606@bellsouth.net> References: <49BA9E1E.4090606@bellsouth.net> Message-ID: <20090313202359.GB17743@topoi.pooq.com> On Fri, Mar 13, 2009 at 12:55:42PM -0500, Martin Bishop wrote: > Is there any chance that "classic" books on Modula-3 like "Modula-3" by > Harbison (I own a copy, it's a great book) or "Systems Programming With > Modula-3" by Nelson might one day be released online? > > They aren't in print anymore, and I can't imagine there is much demand > for them...I found "Modula-3" used for $1 on Amazon, but "Systems > Programming With Modula-3" is $40 at it's cheapest, used :( Is there any chance of contacting the author(s)? -- hendrik From rodney.bates at wichita.edu Fri Mar 13 22:31:24 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 13 Mar 2009 16:31:24 -0500 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <49BA9E1E.4090606@bellsouth.net> References: <49BA9E1E.4090606@bellsouth.net> Message-ID: <49BAD0AC.6050806@wichita.edu> I have maybe 2 or 3 copies of SPwM3. I have occasionally thought about trying to acquire the copyright from Prentice-Hall, but never got around to investigating. There are others: Harbison: "Modula-3", also Prentice-Hall Boszormenyi & Weich "Programming in Modula-3", Springer-Verlag Sedgewick: Algorithms in Modula-3", Addison-Wesley I am especially interested in the last one. The second and third are language tutorials. Does anyone have any idea whether it is better to first contact the author or the publisher? Presumably, the publisher owns all rights, but there is a royalty contract with the author. Perhaps we could create a nonprofit foundation or something, to receive copyrights by whatever means and hold them to keep things like this available. Martin Bishop wrote: > Is there any chance that "classic" books on Modula-3 like "Modula-3" by > Harbison (I own a copy, it's a great book) or "Systems Programming With > Modula-3" by Nelson might one day be released online? > > They aren't in print anymore, and I can't imagine there is much demand > for them...I found "Modula-3" used for $1 on Amazon, but "Systems > Programming With Modula-3" is $40 at it's cheapest, used :( From mika at async.caltech.edu Sat Mar 14 08:04:28 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 14 Mar 2009 00:04:28 -0700 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: Your message of "Fri, 13 Mar 2009 12:55:42 CDT." <49BA9E1E.4090606@bellsouth.net> Message-ID: <200903140704.n2E74S3i079116@camembert.async.caltech.edu> Hi Martin, I once emailed the publisher about permission to reproduce parts of these books for a class I was teaching, and all I got was silence. Harbison's book was listed as a "print on demand" book for a while, if I remember right. Most of Nelson's book is already available online (which chapters are not?), albeit in a less organized way. Last time I bought Nelson, I found it cheaper at amazon.co.uk, and they had several copies for < $10. Try www.addall.com or a similar search engine... Mika Martin Bishop writes: >Is there any chance that "classic" books on Modula-3 like "Modula-3" by >Harbison (I own a copy, it's a great book) or "Systems Programming With >Modula-3" by Nelson might one day be released online? > >They aren't in print anymore, and I can't imagine there is much demand >for them...I found "Modula-3" used for $1 on Amazon, but "Systems >Programming With Modula-3" is $40 at it's cheapest, used :( From martinbishop at bellsouth.net Sat Mar 14 19:52:02 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Sat, 14 Mar 2009 13:52:02 -0500 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <20090313202359.GB17743@topoi.pooq.com> References: <49BA9E1E.4090606@bellsouth.net> <20090313202359.GB17743@topoi.pooq.com> Message-ID: <49BBFCD2.5000505@bellsouth.net> Well, I looked around, but it's surprisingly hard to find Greg Nelson... I believe his full name is actually Charles Greg Nelson, but it's still difficult...I think he was last at HP in 2007? No idea where he works now, nor where he could be contacted. hendrik at topoi.pooq.com wrote: > On Fri, Mar 13, 2009 at 12:55:42PM -0500, Martin Bishop wrote: >> Is there any chance that "classic" books on Modula-3 like "Modula-3" by >> Harbison (I own a copy, it's a great book) or "Systems Programming With >> Modula-3" by Nelson might one day be released online? >> >> They aren't in print anymore, and I can't imagine there is much demand >> for them...I found "Modula-3" used for $1 on Amazon, but "Systems >> Programming With Modula-3" is $40 at it's cheapest, used :( > > Is there any chance of contacting the author(s)? > > -- hendrik > > From martinbishop at bellsouth.net Sat Mar 14 19:50:39 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Sat, 14 Mar 2009 13:50:39 -0500 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <49BAD0AC.6050806@wichita.edu> References: <49BA9E1E.4090606@bellsouth.net> <49BAD0AC.6050806@wichita.edu> Message-ID: <49BBFC7F.4070704@bellsouth.net> I too am interested in the Sedgewick book, which seems very rare. Let me know if you ever find it somewhere for a good price. Rodney M. Bates wrote: > I have maybe 2 or 3 copies of SPwM3. I have occasionally thought about > trying to acquire the copyright from Prentice-Hall, but never got around > to investigating. > > There are others: > > Harbison: "Modula-3", also Prentice-Hall > Boszormenyi & Weich "Programming in Modula-3", Springer-Verlag > Sedgewick: Algorithms in Modula-3", Addison-Wesley > > I am especially interested in the last one. The second and third > are language tutorials. > > Does anyone have any idea whether it is better to first contact the author > or the publisher? Presumably, the publisher owns all rights, but there > is a royalty contract with the author. > > Perhaps we could create a nonprofit foundation or something, to receive > copyrights by whatever means and hold them to keep things like this > available. > > > Martin Bishop wrote: >> Is there any chance that "classic" books on Modula-3 like "Modula-3" by >> Harbison (I own a copy, it's a great book) or "Systems Programming With >> Modula-3" by Nelson might one day be released online? >> >> They aren't in print anymore, and I can't imagine there is much demand >> for them...I found "Modula-3" used for $1 on Amazon, but "Systems >> Programming With Modula-3" is $40 at it's cheapest, used :( > > From martinbishop at bellsouth.net Sat Mar 14 20:20:05 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Sat, 14 Mar 2009 14:20:05 -0500 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <94E563AF-610A-4417-9A4D-05D2F253E0AC@cs.purdue.edu> References: <49BA9E1E.4090606@bellsouth.net> <20090313202359.GB17743@topoi.pooq.com> <49BBFCD2.5000505@bellsouth.net> <94E563AF-610A-4417-9A4D-05D2F253E0AC@cs.purdue.edu> Message-ID: <49BC0365.1070101@bellsouth.net> Ah, and from the email I found http://www.perlnelson.org/ which seems to be a website for the Nelson family. I suppose that would be a good place to contact him. Tony Hosking wrote: > Last contact I had with Greg Nelson was this e-mail... > > Begin forwarded message: >> From: "Greg Nelson" >> Date: 25 March 2006 10:43:52 GMT+11:00 >> To: hosking at cs.purdue.edu >> Subject: Some progress >> Reply-To: greg at perlnelson.org >> >> Antony, >> >> Thank you for your help. By following your advice I have successfully >> downloaded CM3 to my Linux machine, and used it to compile and execute >> the program that prints "Hello world". But when I try to apply it to >> an m3makefile that imports "ui" and compiles a program that >> Trestle.Installs a TextVBT that displays the text "Hello Trestle", I >> get an error message that I interpret to mean "ui package not found". >> And I am concerned that I cannot find any evidence of the ui package >> or of the Juno-2 packages that are my goal. (I hope to use Juno-2 to >> produce an educational video.) >> >> Is there still hope? Would you like to suggest a next step for me? >> >> >> Greg Nelson >> greg at perlnelson.org >> 839 Richardson Ct Palo Alto, CA USA 94303 >> (650) 856 8103 (home) (650) 856 8103 (office) (650) 954 5338 (mobile) > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 15 Mar 2009, at 05:52, Martin Bishop wrote: > >> Well, I looked around, but it's surprisingly hard to find Greg Nelson... >> I believe his full name is actually Charles Greg Nelson, but it's still >> difficult...I think he was last at HP in 2007? No idea where he works >> now, nor where he could be contacted. >> >> hendrik at topoi.pooq.com wrote: >>> On Fri, Mar 13, 2009 at 12:55:42PM -0500, Martin Bishop wrote: >>>> Is there any chance that "classic" books on Modula-3 like "Modula-3" by >>>> Harbison (I own a copy, it's a great book) or "Systems Programming With >>>> Modula-3" by Nelson might one day be released online? >>>> >>>> They aren't in print anymore, and I can't imagine there is much demand >>>> for them...I found "Modula-3" used for $1 on Amazon, but "Systems >>>> Programming With Modula-3" is $40 at it's cheapest, used :( >>> >>> Is there any chance of contacting the author(s)? >>> >>> -- hendrik >>> >>> > > From hosking at cs.purdue.edu Sat Mar 14 20:16:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 15 Mar 2009 06:16:26 +1100 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <49BBFCD2.5000505@bellsouth.net> References: <49BA9E1E.4090606@bellsouth.net> <20090313202359.GB17743@topoi.pooq.com> <49BBFCD2.5000505@bellsouth.net> Message-ID: <94E563AF-610A-4417-9A4D-05D2F253E0AC@cs.purdue.edu> Last contact I had with Greg Nelson was this e-mail... Begin forwarded message: > From: "Greg Nelson" > Date: 25 March 2006 10:43:52 GMT+11:00 > To: hosking at cs.purdue.edu > Subject: Some progress > Reply-To: greg at perlnelson.org > > Antony, > > Thank you for your help. By following your advice I have > successfully downloaded CM3 to my Linux machine, and used it to > compile and execute the program that prints "Hello world". But when > I try to apply it to an m3makefile that imports "ui" and compiles a > program that Trestle.Installs a TextVBT that displays the text > "Hello Trestle", I get an error message that I interpret to mean "ui > package not found". And I am concerned that I cannot find any > evidence of the ui package or of the Juno-2 packages that are my > goal. (I hope to use Juno-2 to produce an educational video.) > > Is there still hope? Would you like to suggest a next step for me? > > > Greg Nelson > greg at perlnelson.org > 839 Richardson Ct Palo Alto, CA USA 94303 > (650) 856 8103 (home) (650) 856 8103 (office) (650) 954 5338 (mobile) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Mar 2009, at 05:52, Martin Bishop wrote: > Well, I looked around, but it's surprisingly hard to find Greg > Nelson... > I believe his full name is actually Charles Greg Nelson, but it's > still > difficult...I think he was last at HP in 2007? No idea where he works > now, nor where he could be contacted. > > hendrik at topoi.pooq.com wrote: >> On Fri, Mar 13, 2009 at 12:55:42PM -0500, Martin Bishop wrote: >>> Is there any chance that "classic" books on Modula-3 like >>> "Modula-3" by >>> Harbison (I own a copy, it's a great book) or "Systems Programming >>> With >>> Modula-3" by Nelson might one day be released online? >>> >>> They aren't in print anymore, and I can't imagine there is much >>> demand >>> for them...I found "Modula-3" used for $1 on Amazon, but "Systems >>> Programming With Modula-3" is $40 at it's cheapest, used :( >> >> Is there any chance of contacting the author(s)? >> >> -- hendrik >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Mar 15 00:00:59 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 15 Mar 2009 00:00:59 +0100 (CET) Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <49BAD0AC.6050806@wichita.edu> References: <49BA9E1E.4090606@bellsouth.net> <49BAD0AC.6050806@wichita.edu> Message-ID: On Fri, 13 Mar 2009, Rodney M. Bates wrote: > I have maybe 2 or 3 copies of SPwM3. I have occasionally thought about > trying to acquire the copyright from Prentice-Hall, but never got around > to investigating. > > There are others: > > Harbison: "Modula-3", also Prentice-Hall > Boszormenyi & Weich "Programming in Modula-3", Springer-Verlag > Sedgewick: Algorithms in Modula-3", Addison-Wesley > > I am especially interested in the last one. The second and third > are language tutorials. I was very disappointed when I got the Sedgewick book. They explicitly try to not use nice language features in their variants for several languages, so this is C translated to Modula-3. They don't use enumeration types although this is often most appropriate, they use global variables without need, I remember they don't use NEW, etc. I think it's better to have the C variant of the book and enjoy porting and thus simplifying the programs to good style Modula-3. From jay.krell at cornell.edu Sun Mar 15 00:20:06 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 14 Mar 2009 23:20:06 +0000 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <49BBFC7F.4070704@bellsouth.net> References: <49BA9E1E.4090606@bellsouth.net> <49BAD0AC.6050806@wichita.edu> <49BBFC7F.4070704@bellsouth.net> Message-ID: Amazon has a few copies of the Sedgewick book used for under $50. Just search, on the Amazon site, for "robert sedgewick modula-3". Indeed they only show one new copy, for $200. - Jay > Date: Sat, 14 Mar 2009 13:50:39 -0500 > From: martinbishop@ > > I too am interested in the Sedgewick book, which seems very rare. Let > me know if you ever find it somewhere for a good price. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Mar 15 11:24:09 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 15 Mar 2009 10:24:09 +0000 Subject: [M3devel] linuxlibc6 jmpbuf size? Message-ID: The Linuxlibc6 jmpbuf size looks clearly wrong, just slightly inflated. It should be 39 * address, not 40. Any objections to fixing it? This is the one that fits the signal mask. Only 6 addresses are needed if signal mask isn't saved. Plus 1 to record if it is saved. Plus 1024 bits for a glibc signal mask, even though the kernel only supports 128 signals on mips and 64 on all others..big waste imho.. 6 + 1 + 1024/32 = 39. Hm. I rather think we should shorten it to 6, 7, or 11 really, after confirming we can. (11: 6 for registers, 1 to indicate if signal mask saved, 4 for signal mask; or 7: 6 for registers and 1 to hold zero to indicate signal mask not saved; or 6: registers and implied/known no signal mask saved, if that is the case, I have to check). See http://lists.uclibc.org/pipermail/uclibc/2008-December/041674.html for details on the signal mask size.. - Jay From hosking at cs.purdue.edu Sun Mar 15 17:05:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Mar 2009 03:05:58 +1100 Subject: [M3devel] linuxlibc6 jmpbuf size? In-Reply-To: References: Message-ID: Have you checked all the alignments? On 15 Mar 2009, at 21:24, Jay wrote: > > The Linuxlibc6 jmpbuf size looks clearly wrong, just slightly > inflated. > It should be 39 * address, not 40. > Any objections to fixing it? > > > This is the one that fits the signal mask. > Only 6 addresses are needed if signal mask isn't saved. > Plus 1 to record if it is saved. > Plus 1024 bits for a glibc signal mask, even though the kernel only > supports 128 signals on mips and 64 on all others..big waste imho.. > > > 6 + 1 + 1024/32 = 39. > > Hm. I rather think we should shorten it to 6, 7, or 11 really, after > confirming we can. > (11: 6 for registers, 1 to indicate if signal mask saved, 4 for > signal mask; or 7: 6 for registers and 1 to hold zero to indicate > signal mask not saved; or 6: registers and implied/known no signal > mask saved, if that is the case, I have to check). > > See > http://lists.uclibc.org/pipermail/uclibc/2008-December/041674.html > > for details on the signal mask size.. > > - Jay From jay.krell at cornell.edu Sun Mar 15 19:13:32 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 15 Mar 2009 18:13:32 +0000 Subject: [M3devel] linuxlibc6 jmpbuf size? In-Reply-To: References: Message-ID: I hadn't, but it is 4, and that is factored into printing the size in C, though not factored into adding up the size by hand. I did both. I first noticed the disprepancy when a change I had locally made Csetjmp.i3 not compile, (missing Usignal.sigset_t) so I ran config.c. Though since config.c is kind of complicated, also ran: jay at localhost ~ $ uname -a Linux localhost 2.6.25-gentoo-r7 #5 Sun Oct 5 18:59:56 Local time zone must be set--see zic manua i5 86 Geode(TM) Integrated Processor by AMD PCS AuthenticAMD GNU/Linux jay at localhost ~ $ cat 1.c #include #include typedef unsigned U; int main() { jmp_buf jb[2]; printf("%u\n", (U)sizeof(jb)); printf("%u\n", (U)sizeof(jmp_buf)); printf("%u\n", (U)__alignof(jmp_buf)); return 0; } jay at localhost ~ $ cc 1.c .jay at localhost ~ $ ./a.out 312 156 4 (eek, hadn't noticed the clock being wrong before, though I had noticed the timezone) - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] linuxlibc6 jmpbuf size? > Date: Mon, 16 Mar 2009 03:05:58 +1100 > > Have you checked all the alignments? > > On 15 Mar 2009, at 21:24, Jay wrote: > >> >> The Linuxlibc6 jmpbuf size looks clearly wrong, just slightly >> inflated. >> It should be 39 * address, not 40. >> Any objections to fixing it? >> >> >> This is the one that fits the signal mask. >> Only 6 addresses are needed if signal mask isn't saved. >> Plus 1 to record if it is saved. >> Plus 1024 bits for a glibc signal mask, even though the kernel only >> supports 128 signals on mips and 64 on all others..big waste imho.. >> >> >> 6 + 1 + 1024/32 = 39. >> >> Hm. I rather think we should shorten it to 6, 7, or 11 really, after >> confirming we can. >> (11: 6 for registers, 1 to indicate if signal mask saved, 4 for >> signal mask; or 7: 6 for registers and 1 to hold zero to indicate >> signal mask not saved; or 6: registers and implied/known no signal >> mask saved, if that is the case, I have to check). >> >> See >> http://lists.uclibc.org/pipermail/uclibc/2008-December/041674.html >> >> for details on the signal mask size.. >> >> - Jay > From jay.krell at cornell.edu Sun Mar 15 20:15:56 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 15 Mar 2009 19:15:56 +0000 Subject: [M3devel] recent problems? Message-ID: I'm seeing some problems lately. Maybe it is just me. Some of them I've had over a week (ie: before my (most) recent changes), some of them even if recently appeared I verified without my (most) recent changes. On Cygwin 1.5, mklib always crashes. I haven't been able to debug it. This has been over a week. I've had to stop using Cygwin for Modula-3 development on this machine. I have a good repro but hadn't had luck yet debugging it. Basically if I shorten the mklib command line (in the response file) substantially, no crash. There is a cut off somewhere. On Cygwin 1.7 machine, stubgen in obliqparse usually but not always hangs. It hangs nowhere else. This I verified occured without my recent changes. I only just in the past few days tried Cygwin 1.7. mklib works fine here. Of course since this is somewhat intermittent, maybe it isn't a new problem. I've only tried Cygwin 1.5 and 1.7 on one machine each, separate machines, though they do coexist ok on one machine. 1.7 seemed much faster (on an unimpressive machine), though 1.7 binares apparently don't run on 1.5 -- at least not if they use assert(). 1.7 is a recent past or future release, a long time in the works, drops Win9x support, lots of good sounding changes. I should run m3tests more, maybe they will reveal the crash or the hang as well. On LINUXLIBC6 on one machine stubgen was crashing at least in one directory. But I think this stopped happening. Cygwin being broken pushes me to other platforms more, probably a good thing. I'm loathe to debug the hang. When it occurs I can't see any stacks in gdb. I can see in strace.. I think we are waiting for all the threads to suspend themselves. I'll probably try moving back to Win32 threads and see if it clears up. I know that's not great. There isn't a clear implied question and I know I should/need to look into these, but I also thought I shouldn't keep this to myself. I also understand the philosophy of stopping changes when there are problems, to stop further damage, but, of course, I'm very confident in my changes (always..), have been testing them on other platforms, and looking them over extra extra since I know of these other problems. I'm not sure any problem on Cygwin is worrisome really. I think the underlying code is kind of gnarly and I don't think anyone uses this platform, though people asked for it. But I did have a crash on LINUXLIBC6. - Jay From hosking at cs.purdue.edu Sun Mar 15 22:10:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Mar 2009 08:10:05 +1100 Subject: [M3devel] recent problems? In-Reply-To: References: Message-ID: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> You might have structure sizes wrong and your stack will get shifted around as the command line changes length. You get some data in a structure wrong and then hit the wrong stack org and you might see problems like this. I am not running things totally off of the head, so if the problem was introduced recently it might only now be seen. On 16 Mar 2009, at 06:15, Jay wrote: > > I'm seeing some problems lately. Maybe it is just me. > Some of them I've had over a week (ie: before my (most) recent > changes), > some of them even if recently appeared I verified without my (most) > recent changes. > > On Cygwin 1.5, mklib always crashes. I haven't been able to debug it. > This has been over a week. > I've had to stop using Cygwin for Modula-3 development on this > machine. > I have a good repro but hadn't had luck yet debugging it. > Basically if I shorten the mklib command line (in the response > file) substantially, no crash. > There is a cut off somewhere. > > On Cygwin 1.7 machine, stubgen in obliqparse usually but not always > hangs. > It hangs nowhere else. > This I verified occured without my recent changes. > I only just in the past few days tried Cygwin 1.7. > mklib works fine here. > Of course since this is somewhat intermittent, maybe it isn't a new > problem. > > I've only tried Cygwin 1.5 and 1.7 on one machine each, separate > machines, > though they do coexist ok on one machine. > 1.7 seemed much faster (on an unimpressive machine), though 1.7 > binares > apparently don't run on 1.5 -- at least not if they use assert(). > 1.7 is a recent past or future release, a long time in the works, > drops Win9x support, lots of good sounding changes. > > I should run m3tests more, maybe they will reveal the crash or the > hang as well. > > On LINUXLIBC6 on one machine stubgen was crashing at least in one > directory. > But I think this stopped happening. > > Cygwin being broken pushes me to other platforms more, probably a > good thing. > I'm loathe to debug the hang. When it occurs I can't see any stacks > in gdb. I can see in strace.. > I think we are waiting for all the threads to suspend themselves. > I'll probably try moving back to Win32 threads and see if it clears > up. > I know that's not great. > There isn't a clear implied question and I know I should/need to > look into these, > but I also thought I shouldn't keep this to myself. I also > understand the philosophy > of stopping changes when there are problems, to stop further > damage, but, of course, > I'm very confident in my changes (always..), have been testing them > on other platforms, > and looking them over extra extra since I know of these other > problems. > > I'm not sure any problem on Cygwin is worrisome really. > I think the underlying code is kind of gnarly and I don't think > anyone uses this platform, though people asked for it. > But I did have a crash on LINUXLIBC6. > > - Jay From martinbishop at bellsouth.net Mon Mar 16 01:22:59 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Sun, 15 Mar 2009 19:22:59 -0500 Subject: [M3devel] [Fwd: Re: "Systems Programming With Modula-3" available?] Message-ID: <49BD9BE3.6050900@bellsouth.net> This is the email (and response) I got from Greg Nelson. -------------- next part -------------- An embedded message was scrubbed... From: Greg Nelson Subject: Re: "Systems Programming With Modula-3" available? Date: Sun, 15 Mar 2009 14:49:03 -0700 Size: 3045 URL: From jay.krell at cornell.edu Mon Mar 16 02:09:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 01:09:52 +0000 Subject: [M3devel] FW: trimmed down more portable Unix *.i3 files In-Reply-To: <20090316003949.40CB110D60EA@birch.elegosoft.com> References: <20090316003949.40CB110D60EA@birch.elegosoft.com> Message-ID: This is a significant change. I have used these files (older versions often) on a number of platforms already: AMD64_{LINUX,FREEBSD}, I386_OPENBSD, PA32_HPUX, incomplete PA64_HPUX, Cygwin, PPC_LINUX, SPARC64_SOLARIS, MIP64_OPENBSD (I don't think I finished that), others maybe. - Jay ---------------------------------------- > Date: Mon, 16 Mar 2009 01:39:49 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/03/16 01:39:49 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: m3makefile > cm3/m3-libs/m3core/src/unix/linux-libc6/: m3makefile > > Log message: > switch LINUXLIBC6 to the trimmed down more portable Unix *.i3 files, > except for Usignal.i3 and Uucontext.i3. Usignal.i3 and Uucontext.i3 > are left alone in order to keep the user thread code compilable, > though it is not expected to work for other long standing reasons. > From jay.krell at cornell.edu Mon Mar 16 02:39:51 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 01:39:51 +0000 Subject: [M3devel] eliminating platform-specifity of pthread_t? Message-ID: pthread_t 1) do nothing; leave it as platform-dependent 2) Widen it to INTEGER or ADDRESS and declare that is portable and correct. Put in an assert that pthread_t fits in size_t/void*. This is often correct, and where it isn't, it is probably ok. correct: OpenBSD, FreeBSD, NetBSD, all or probably all 32bit platforms, Cygwin, Darwin, Linux wasteful: 64bit HP-UX, 64bit Solaris; which apparently both always use a 32bit integer for pthread_t not yet determined: Tru64, AIX, Irix (including 32bit AIX, Irix; I have these systems.) Given that its neighbors on both sides are pointers, this isn't likely to consume any extra space on most platforms (but maybe on AMD64_SOLARIS?) Odds are high that passing a pointer instead of 32bit integer is ok on all platforms, but wrappers can be introduced to make that safer, like how I did for mode_t. 3) Some sort of C wrapping, that I haven't thought of yet. Well, there are some candidates, more and less satisfactory. 3a) heap allocate it; not satisfactory 3b) Put it at the end of Activation and use it with C wrappers fairly satisfactory, just that the system-dependent FloatMode.ThreadState and RTHeapRep.ThreadState have to be accounted for, somehow. Either by having the C know their definition on all platforms, ok. Or by having the Modula-3 code pass that data to the C code. These are both signficantly less satisfactory imho than any other C wrapping I have put in. I think #2 with wrappers is my favorite. - Jay From carson at taltos.org Mon Mar 16 04:38:27 2009 From: carson at taltos.org (Carson Gaspar) Date: Sun, 15 Mar 2009 20:38:27 -0700 Subject: [M3devel] cvsup and cm3 - drama galore! Any help for Uexec_WNOHANG? Message-ID: <49BDC9B3.3020808@taltos.org> I want to end up with a working cvsup for our RHEL5 U4 x86_64 servers (a working 32-bit binary is fine...). So I tried building cm3 and ran into problems trying to bootstrap. The list archives said "use newer source". So I tried. And the latest snapshots failed to build. I saw a message complaining about the regression (sadly sans solution), so I grabbed source from CVS as of Jan 31, 2009. That built! So now I try building cvsup. Then I apply the cm3 patch and try again. Then I manually hack "SchedulerPOSIX" to "Scheduler" and try again (thank my lucky stars for Google!). So now I _almost_ have it building, but it fails on FSServerU.m3, complaining about an undefined reference to Uexec_WNOHANG. And here I sit, stumped. I see a C sourse file Uconstants.c in the cm3 distribution that looks like it _ought_ to define it, but obviously something is unhappy... When was the last time somebody successfully built cvsup with cm3 on Linux? I'll gladly bootstrap from some known good point, but I'd rather avoid doing a binary search to find a working compiler... -- Carson From hendrik at topoi.pooq.com Mon Mar 16 03:07:02 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 15 Mar 2009 22:07:02 -0400 Subject: [M3devel] [Fwd: Re: "Systems Programming With Modula-3" available?] In-Reply-To: <49BD9BE3.6050900@bellsouth.net> References: <49BD9BE3.6050900@bellsouth.net> Message-ID: <20090316020702.GC24734@topoi.pooq.com> On Sun, Mar 15, 2009 at 07:22:59PM -0500, Martin Bishop wrote: > This is the email (and response) I got from Greg Nelson. > X-Account-Key: account2 > X-Mozilla-Keys: > Authentication-Results: isp.att.net; > domainkey=pass (no signature error) header.From=gnelson at gmail.com > Authentication-Results: isp.att.net; > dkim=pass (no signature error) header.i=@gmail.com > X-Originating-IP: [209.85.198.246] > Reply-To: greg at perlnelson.org > Subject: Re: "Systems Programming With Modula-3" available? > From: Greg Nelson > To: Martin Bishop > > I haven't studied the contract with Prentice-Hall, but I'm afraid it > is bound to give them the copyright. I have asked them before to > please print a second edition. I will try again. If they refuse, I'm > not sure there is anything I can do to help. But in case it is of any > help to you, I will remark that II think that the TeX sources for the > book are stored among the publicly released Modula-3 packages. Which puts the whole thing in a difficult legal position. If the rights were given away under the original Modula-3 license, just what did Prentice-Hall buy, what did they think they bought, and what legal position will that put Greg? And if they were sold to Prentice-Hall before they were given away, just what was given away? And if Prentice-Hall refuses even to reprint and the book has been years out of pront, what rights revert to Greg? There are standard contract terms here (which Prentice hall may not have used) and there is applicable law, which varies from country to country. For example, Canadian law permits some copying of entire books under some circumstance if they are permanently out of print.... Even if Prentice-Hall refuses, they may be willing to return the rights to a book they have no intention of ever reprinting. -- hendrik From wagner at elegosoft.com Mon Mar 16 07:47:09 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 16 Mar 2009 07:47:09 +0100 Subject: [M3devel] cvsup and cm3 - drama galore! Any help for Uexec_WNOHANG? In-Reply-To: <49BDC9B3.3020808@taltos.org> References: <49BDC9B3.3020808@taltos.org> Message-ID: <20090316074709.xoymn3nx0gk8ggc4@mail.elegosoft.com> Quoting Carson Gaspar : > I want to end up with a working cvsup for our RHEL5 U4 x86_64 servers (a > working 32-bit binary is fine...). > > So I tried building cm3 and ran into problems trying to bootstrap. The > list archives said "use newer source". So I tried. And the latest > snapshots failed to build. I saw a message complaining about the > regression (sadly sans solution), so I grabbed source from CVS as of Jan > 31, 2009. That built! > > So now I try building cvsup. Then I apply the cm3 patch and try again. > Then I manually hack "SchedulerPOSIX" to "Scheduler" and try again > (thank my lucky stars for Google!). So now I _almost_ have it building, > but it fails on FSServerU.m3, complaining about an undefined reference > to Uexec_WNOHANG. And here I sit, stumped. I see a C sourse file > Uconstants.c in the cm3 distribution that looks like it _ought_ to > define it, but obviously something is unhappy... > > When was the last time somebody successfully built cvsup with cm3 on > Linux? I'll gladly bootstrap from some known good point, but I'd rather > avoid doing a binary search to find a working compiler... It's not Linux, it's the 64 bit targets on Intel processors which are rather new and unpolished. I don't think the WNOHANG problem is due to that, though; I rather think it may have been `optimized away' during a perhaps too rigorous code clean-up recently. Jay, could it be that this constant is acceidently missing in newer sources? This reminds me that we should add cvsup as a cm3 project and include it in our regression tests. I'll try to do that some time soon. Don't panic; we'll be able to get cvsup to compile ;-) Regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Mar 16 08:54:53 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 07:54:53 +0000 Subject: [M3devel] cvsup and cm3 - minor problems Any help for Uexec_WNOHANG? In-Reply-To: <20090316074709.xoymn3nx0gk8ggc4@mail.elegosoft.com> References: <49BDC9B3.3020808@taltos.org> <20090316074709.xoymn3nx0gk8ggc4@mail.elegosoft.com> Message-ID: I don't see that Carson is on this email. Please build and ship m3core from current source. Specifically, m3core/src/unix/Common/Uconstants.c has: #define X(x) const int Uexec__##x = x; X(WNOHANG) it used to have just one underscore: #define X(x) const int Uexec_##x = x; X(WNOHANG) If it is really necessary, we could put both in for increased compat -- but in that case, might as well have left it with one underscore. As well, you can temporarily change it to whatever you find the value in /usr/include (1 on Linux/x86), or, depending on your code, 0 might be good. 0 is good if the thread waiting on a process is meant to block until the child process exits. Use of nohang historically in the cm3 code is only for the benefit of user threads -- it is inefficient and imho not important. I can imagine an app where one thread polls multiple child processes though, which might require the nohang. (I really like the Windows model where process, files, sockets, threads...all are waiting with the same functions...) > it's the 64 bit targets on Intel processors which are > rather new and unpolished. If you have particulars, please let me know. I admit I'm not using them..I'm nervous as to what my electricity bill would be if I actually left everything powered on and running the Tinderbox.. I know there is the thing..we should probe if /usr/lib64 exists and use if it so, else /usr/lib. > This reminds me that we should add cvsup as a cm3 project and include Yes, anything you can add to the "std" package set, please do. - Jay ---------------------------------------- > Date: Mon, 16 Mar 2009 07:47:09 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] cvsup and cm3 - drama galore! Any help for Uexec_WNOHANG? > > Quoting Carson Gaspar : > >> I want to end up with a working cvsup for our RHEL5 U4 x86_64 servers (a >> working 32-bit binary is fine...). >> >> So I tried building cm3 and ran into problems trying to bootstrap. The >> list archives said "use newer source". So I tried. And the latest >> snapshots failed to build. I saw a message complaining about the >> regression (sadly sans solution), so I grabbed source from CVS as of Jan >> 31, 2009. That built! >> >> So now I try building cvsup. Then I apply the cm3 patch and try again. >> Then I manually hack "SchedulerPOSIX" to "Scheduler" and try again >> (thank my lucky stars for Google!). So now I _almost_ have it building, >> but it fails on FSServerU.m3, complaining about an undefined reference >> to Uexec_WNOHANG. And here I sit, stumped. I see a C sourse file >> Uconstants.c in the cm3 distribution that looks like it _ought_ to >> define it, but obviously something is unhappy... >> >> When was the last time somebody successfully built cvsup with cm3 on >> Linux? I'll gladly bootstrap from some known good point, but I'd rather >> avoid doing a binary search to find a working compiler... > > It's not Linux, it's the 64 bit targets on Intel processors which are > rather new and unpolished. I don't think the WNOHANG problem is due to > that, though; I rather think it may have been `optimized away' during > a perhaps too rigorous code clean-up recently. > > Jay, could it be that this constant is acceidently missing in newer > sources? > > This reminds me that we should add cvsup as a cm3 project and include > it in our regression tests. I'll try to do that some time soon. > > Don't panic; we'll be able to get cvsup to compile ;-) > > Regards, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Mar 16 08:56:08 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 07:56:08 +0000 Subject: [M3devel] cvsup and cm3 - minor problems Any help for Uexec_WNOHANG? In-Reply-To: <20090316074709.xoymn3nx0gk8ggc4@mail.elegosoft.com> References: <49BDC9B3.3020808@taltos.org> <20090316074709.xoymn3nx0gk8ggc4@mail.elegosoft.com> Message-ID: [adding Carson this time] Please build and ship m3core from current source. Specifically, m3core/src/unix/Common/Uconstants.c has: #define X(x) const int Uexec__##x = x; X(WNOHANG) it used to have just one underscore: #define X(x) const int Uexec_##x = x; X(WNOHANG) If it is really necessary, we could put both in for increased compat -- but in that case, might as well have left it with one underscore. As well, you can temporarily change it to whatever you find the value in /usr/include (1 on Linux/x86), or, depending on your code, 0 might be good. 0 is good if the thread waiting on a process is meant to block until the child process exits. Use of nohang historically in the cm3 code is only for the benefit of user threads -- it is inefficient and imho not important. I can imagine an app where one thread polls multiple child processes though, which might require the nohang. (I really like the Windows model where process, files, sockets, threads...all are waiting with the same functions...) > it's the 64 bit targets on Intel processors which are > rather new and unpolished. If you have particulars, please let me know. I admit I'm not using them..I'm nervous as to what my electricity bill would be if I actually left everything powered on and running the Tinderbox.. I know there is the thing..we should probe if /usr/lib64 exists and use if it so, else /usr/lib. > This reminds me that we should add cvsup as a cm3 project and include Yes, anything you can add to the "std" package set, please do. - Jay > > > ---------------------------------------- >> Date: Mon, 16 Mar 2009 07:47:09 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com; jay.krell at cornell.edu >> Subject: Re: [M3devel] cvsup and cm3 - drama galore! Any help for Uexec_WNOHANG? >> >> Quoting Carson Gaspar : >> >>> I want to end up with a working cvsup for our RHEL5 U4 x86_64 servers (a >>> working 32-bit binary is fine...). >>> >>> So I tried building cm3 and ran into problems trying to bootstrap. The >>> list archives said "use newer source". So I tried. And the latest >>> snapshots failed to build. I saw a message complaining about the >>> regression (sadly sans solution), so I grabbed source from CVS as of Jan >>> 31, 2009. That built! >>> >>> So now I try building cvsup. Then I apply the cm3 patch and try again. >>> Then I manually hack "SchedulerPOSIX" to "Scheduler" and try again >>> (thank my lucky stars for Google!). So now I _almost_ have it building, >>> but it fails on FSServerU.m3, complaining about an undefined reference >>> to Uexec_WNOHANG. And here I sit, stumped. I see a C sourse file >>> Uconstants.c in the cm3 distribution that looks like it _ought_ to >>> define it, but obviously something is unhappy... >>> >>> When was the last time somebody successfully built cvsup with cm3 on >>> Linux? I'll gladly bootstrap from some known good point, but I'd rather >>> avoid doing a binary search to find a working compiler... >> >> It's not Linux, it's the 64 bit targets on Intel processors which are >> rather new and unpolished. I don't think the WNOHANG problem is due to >> that, though; I rather think it may have been `optimized away' during >> a perhaps too rigorous code clean-up recently. >> >> Jay, could it be that this constant is acceidently missing in newer >> sources? >> >> This reminds me that we should add cvsup as a cm3 project and include >> it in our regression tests. I'll try to do that some time soon. >> >> Don't panic; we'll be able to get cvsup to compile ;-) >> >> Regards, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Mon Mar 16 09:57:40 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 08:57:40 +0000 Subject: [M3devel] recent problems? In-Reply-To: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> References: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> Message-ID: Thanks. Here is another one. I found this testing moving PPC_DARWIN to "my headers". formsedit crashes during startup roughly more than half the times I start up, but not every time. The stack is always the same. I'll test it without my change. I think it'll happen either way, but I'll see. Yes, it recurs without my change, though I double check that my change is really undone. I'll have to dig into this. How does one get the code from CVS corresponding to a date? cvs upd -D ? I'll try that or something, see if I can find when things worked. I should also be able to try the mklib crashing scenario on other platforms. It normally doesn't run on other platforms. stubgen..if I'm ambitious, I can run in a loop on another platform. But I think just moving Cygwin off of pthreads will "fix" it and provide a cleaner base (not due to pthreads, but the Cygwin stuff). Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 [Switching to process 19583 thread 0x2643] 0x0031798c in ScrollerVBTClass__PaintViewWithShadows (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc rollerVBTClass.m3:325 325 VBT.PaintTint(v, r, v.shadow.bg); (gdb) bt #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI X/ScrollerVBTClass.m3:325 #1 0x0031766c in ScrollerVBTClass__PaintView (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV BTClass.m3:292 #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, M3_A0Kbc5_rgn=0xf0284778) at ../ src/lego/POSIX/ScrollerVBTClass.m3:693 #3 0x0031a590 in ScrollerVBTClass__Redisplay (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV BTClass.m3:706 #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../src/vbt/VBTClass.m3:367 #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/VBTRep.m3:601 #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../src/vbt/VBTRep.m3:606 #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) at ../src/thread/PTHREAD/ThreadP Thread.m3:531 #9 0x0132fb58 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr eadPThread.m3:508 #10 0x9002b908 in _pthread_body () (gdb) - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 16 Mar 2009 08:10:05 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > You might have structure sizes wrong and your stack will get shifted > around as the command line changes length. You get some data in a > structure wrong and then hit the wrong stack org and you might see > problems like this. > > I am not running things totally off of the head, so if the problem was > introduced recently it might only now be seen. > > On 16 Mar 2009, at 06:15, Jay wrote: > >> >> I'm seeing some problems lately. Maybe it is just me. >> Some of them I've had over a week (ie: before my (most) recent >> changes), >> some of them even if recently appeared I verified without my (most) >> recent changes. >> >> On Cygwin 1.5, mklib always crashes. I haven't been able to debug it. >> This has been over a week. >> I've had to stop using Cygwin for Modula-3 development on this >> machine. >> I have a good repro but hadn't had luck yet debugging it. >> Basically if I shorten the mklib command line (in the response >> file) substantially, no crash. >> There is a cut off somewhere. >> >> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >> hangs. >> It hangs nowhere else. >> This I verified occured without my recent changes. >> I only just in the past few days tried Cygwin 1.7. >> mklib works fine here. >> Of course since this is somewhat intermittent, maybe it isn't a new >> problem. >> >> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >> machines, >> though they do coexist ok on one machine. >> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >> binares >> apparently don't run on 1.5 -- at least not if they use assert(). >> 1.7 is a recent past or future release, a long time in the works, >> drops Win9x support, lots of good sounding changes. >> >> I should run m3tests more, maybe they will reveal the crash or the >> hang as well. >> >> On LINUXLIBC6 on one machine stubgen was crashing at least in one >> directory. >> But I think this stopped happening. >> >> Cygwin being broken pushes me to other platforms more, probably a >> good thing. >> I'm loathe to debug the hang. When it occurs I can't see any stacks >> in gdb. I can see in strace.. >> I think we are waiting for all the threads to suspend themselves. >> I'll probably try moving back to Win32 threads and see if it clears >> up. >> I know that's not great. >> There isn't a clear implied question and I know I should/need to >> look into these, >> but I also thought I shouldn't keep this to myself. I also >> understand the philosophy >> of stopping changes when there are problems, to stop further >> damage, but, of course, >> I'm very confident in my changes (always..), have been testing them >> on other platforms, >> and looking them over extra extra since I know of these other >> problems. >> >> I'm not sure any problem on Cygwin is worrisome really. >> I think the underlying code is kind of gnarly and I don't think >> anyone uses this platform, though people asked for it. >> But I did have a crash on LINUXLIBC6. >> >> - Jay > From jay.krell at cornell.edu Mon Mar 16 14:16:21 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 13:16:21 +0000 Subject: [M3devel] recent problems? In-Reply-To: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> References: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> Message-ID: mklib seems ok now, having started over with a new checkout, new build. Strange considering what I had already tried, this problem had been plaguing me over a week. stubgen doesn't hang with 1.5, will try 1.7 again/later. But formsedit still crashes during startup intermittently, and Cygwin X apps hang at startup. ugh. I know, I probably caused whatever problem.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] recent problems? > Date: Mon, 16 Mar 2009 08:57:40 +0000 > > > Thanks. > > > Here is another one. > I found this testing moving PPC_DARWIN to "my headers". > formsedit crashes during startup roughly more than > half the times I start up, but not every time. > The stack is always the same. > I'll test it without my change. > I think it'll happen either way, but I'll see. > Yes, it recurs without my change, though I double > check that my change is really undone. > I'll have to dig into this. > > > How does one get the code from CVS corresponding to a date? > cvs upd -D ? > I'll try that or something, see if I can find when things worked. > > > I should also be able to try the mklib crashing scenario > on other platforms. It normally doesn't run on other platforms. > > > stubgen..if I'm ambitious, I can run in a loop on another platform. > But I think just moving Cygwin off of pthreads will "fix" it > and provide a cleaner base (not due to pthreads, but the Cygwin stuff). > > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 > [Switching to process 19583 thread 0x2643] > 0x0031798c in ScrollerVBTClass__PaintViewWithShadows (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc > rollerVBTClass.m3:325 > 325 VBT.PaintTint(v, r, v.shadow.bg); > (gdb) bt > #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI > X/ScrollerVBTClass.m3:325 > #1 0x0031766c in ScrollerVBTClass__PaintView (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV > BTClass.m3:292 > #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, M3_A0Kbc5_rgn=0xf0284778) at ../ > src/lego/POSIX/ScrollerVBTClass.m3:693 > #3 0x0031a590 in ScrollerVBTClass__Redisplay (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV > BTClass.m3:706 > #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../src/vbt/VBTClass.m3:367 > #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 > #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/VBTRep.m3:601 > #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../src/vbt/VBTRep.m3:606 > #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) at ../src/thread/PTHREAD/ThreadP > Thread.m3:531 > #9 0x0132fb58 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr > eadPThread.m3:508 > #10 0x9002b908 in _pthread_body () > (gdb) > > > > - Jay > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Mon, 16 Mar 2009 08:10:05 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] recent problems? >> >> You might have structure sizes wrong and your stack will get shifted >> around as the command line changes length. You get some data in a >> structure wrong and then hit the wrong stack org and you might see >> problems like this. >> >> I am not running things totally off of the head, so if the problem was >> introduced recently it might only now be seen. >> >> On 16 Mar 2009, at 06:15, Jay wrote: >> >>> >>> I'm seeing some problems lately. Maybe it is just me. >>> Some of them I've had over a week (ie: before my (most) recent >>> changes), >>> some of them even if recently appeared I verified without my (most) >>> recent changes. >>> >>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug it. >>> This has been over a week. >>> I've had to stop using Cygwin for Modula-3 development on this >>> machine. >>> I have a good repro but hadn't had luck yet debugging it. >>> Basically if I shorten the mklib command line (in the response >>> file) substantially, no crash. >>> There is a cut off somewhere. >>> >>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>> hangs. >>> It hangs nowhere else. >>> This I verified occured without my recent changes. >>> I only just in the past few days tried Cygwin 1.7. >>> mklib works fine here. >>> Of course since this is somewhat intermittent, maybe it isn't a new >>> problem. >>> >>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>> machines, >>> though they do coexist ok on one machine. >>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>> binares >>> apparently don't run on 1.5 -- at least not if they use assert(). >>> 1.7 is a recent past or future release, a long time in the works, >>> drops Win9x support, lots of good sounding changes. >>> >>> I should run m3tests more, maybe they will reveal the crash or the >>> hang as well. >>> >>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>> directory. >>> But I think this stopped happening. >>> >>> Cygwin being broken pushes me to other platforms more, probably a >>> good thing. >>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>> in gdb. I can see in strace.. >>> I think we are waiting for all the threads to suspend themselves. >>> I'll probably try moving back to Win32 threads and see if it clears >>> up. >>> I know that's not great. >>> There isn't a clear implied question and I know I should/need to >>> look into these, >>> but I also thought I shouldn't keep this to myself. I also >>> understand the philosophy >>> of stopping changes when there are problems, to stop further >>> damage, but, of course, >>> I'm very confident in my changes (always..), have been testing them >>> on other platforms, >>> and looking them over extra extra since I know of these other >>> problems. >>> >>> I'm not sure any problem on Cygwin is worrisome really. >>> I think the underlying code is kind of gnarly and I don't think >>> anyone uses this platform, though people asked for it. >>> But I did have a crash on LINUXLIBC6. >>> >>> - Jay >> From hosking at cs.purdue.edu Mon Mar 16 15:54:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 17 Mar 2009 01:54:34 +1100 Subject: [M3devel] recent problems? In-Reply-To: References: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> Message-ID: This is worrying as it seems some level of instability has been introduced by recent changes. mentor used to be fine. On 17 Mar 2009, at 00:16, Jay wrote: > > mklib seems ok now, having started over with a new checkout, new > build. > Strange considering what I had already tried, this problem had been > plaguing me over a week. > > > stubgen doesn't hang with 1.5, will try 1.7 again/later. > > > But formsedit still crashes during startup intermittently, > and Cygwin X apps hang at startup. > ugh. > I know, I probably caused whatever problem.. > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] recent problems? >> Date: Mon, 16 Mar 2009 08:57:40 +0000 >> >> >> Thanks. >> >> >> Here is another one. >> I found this testing moving PPC_DARWIN to "my headers". >> formsedit crashes during startup roughly more than >> half the times I start up, but not every time. >> The stack is always the same. >> I'll test it without my change. >> I think it'll happen either way, but I'll see. >> Yes, it recurs without my change, though I double >> check that my change is really undone. >> I'll have to dig into this. >> >> >> How does one get the code from CVS corresponding to a date? >> cvs upd -D ? >> I'll try that or something, see if I can find when things worked. >> >> >> I should also be able to try the mklib crashing scenario >> on other platforms. It normally doesn't run on other platforms. >> >> >> stubgen..if I'm ambitious, I can run in a loop on another platform. >> But I think just moving Cygwin off of pthreads will "fix" it >> and provide a cleaner base (not due to pthreads, but the Cygwin >> stuff). >> >> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >> [Switching to process 19583 thread 0x2643] >> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >> rollerVBTClass.m3:325 >> 325 VBT.PaintTint(v, r, v.shadow.bg); >> (gdb) bt >> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >> X/ScrollerVBTClass.m3:325 >> #1 0x0031766c in ScrollerVBTClass__PaintView >> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >> BTClass.m3:292 >> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >> M3_A0Kbc5_rgn=0xf0284778) at ../ >> src/lego/POSIX/ScrollerVBTClass.m3:693 >> #3 0x0031a590 in ScrollerVBTClass__Redisplay >> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >> BTClass.m3:706 >> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../ >> src/vbt/VBTClass.m3:367 >> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >> VBTRep.m3:601 >> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >> src/vbt/VBTRep.m3:606 >> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >> at ../src/thread/PTHREAD/ThreadP >> Thread.m3:531 >> #9 0x0132fb58 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >> eadPThread.m3:508 >> #10 0x9002b908 in _pthread_body () >> (gdb) >> >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] recent problems? >>> >>> You might have structure sizes wrong and your stack will get shifted >>> around as the command line changes length. You get some data in a >>> structure wrong and then hit the wrong stack org and you might see >>> problems like this. >>> >>> I am not running things totally off of the head, so if the problem >>> was >>> introduced recently it might only now be seen. >>> >>> On 16 Mar 2009, at 06:15, Jay wrote: >>> >>>> >>>> I'm seeing some problems lately. Maybe it is just me. >>>> Some of them I've had over a week (ie: before my (most) recent >>>> changes), >>>> some of them even if recently appeared I verified without my (most) >>>> recent changes. >>>> >>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>> it. >>>> This has been over a week. >>>> I've had to stop using Cygwin for Modula-3 development on this >>>> machine. >>>> I have a good repro but hadn't had luck yet debugging it. >>>> Basically if I shorten the mklib command line (in the response >>>> file) substantially, no crash. >>>> There is a cut off somewhere. >>>> >>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>> hangs. >>>> It hangs nowhere else. >>>> This I verified occured without my recent changes. >>>> I only just in the past few days tried Cygwin 1.7. >>>> mklib works fine here. >>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>> problem. >>>> >>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>> machines, >>>> though they do coexist ok on one machine. >>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>> binares >>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>> 1.7 is a recent past or future release, a long time in the works, >>>> drops Win9x support, lots of good sounding changes. >>>> >>>> I should run m3tests more, maybe they will reveal the crash or the >>>> hang as well. >>>> >>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>> directory. >>>> But I think this stopped happening. >>>> >>>> Cygwin being broken pushes me to other platforms more, probably a >>>> good thing. >>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>> in gdb. I can see in strace.. >>>> I think we are waiting for all the threads to suspend themselves. >>>> I'll probably try moving back to Win32 threads and see if it clears >>>> up. >>>> I know that's not great. >>>> There isn't a clear implied question and I know I should/need to >>>> look into these, >>>> but I also thought I shouldn't keep this to myself. I also >>>> understand the philosophy >>>> of stopping changes when there are problems, to stop further >>>> damage, but, of course, >>>> I'm very confident in my changes (always..), have been testing them >>>> on other platforms, >>>> and looking them over extra extra since I know of these other >>>> problems. >>>> >>>> I'm not sure any problem on Cygwin is worrisome really. >>>> I think the underlying code is kind of gnarly and I don't think >>>> anyone uses this platform, though people asked for it. >>>> But I did have a crash on LINUXLIBC6. >>>> >>>> - Jay >>> From mfmorss at aep.com Mon Mar 16 19:33:13 2009 From: mfmorss at aep.com (mfmorss at aep.com) Date: Mon, 16 Mar 2009 14:33:13 -0400 Subject: [M3devel] CM3 on Linux 64-bit Message-ID: I apologize in advance if this is not the right place to ask this. If I use CM3 on Linux 64-bit running on Intel multi-core chips (two quad core chips, actually), do I have a valid expectation that I will be able to implement concurrent multithreading? I tried to discover this on the website, and if it's there, I must have missed it. Thanks in advance. From jay.krell at cornell.edu Mon Mar 16 21:52:49 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 20:52:49 +0000 Subject: [M3devel] CM3 on Linux 64-bit In-Reply-To: References: Message-ID: Yes. The Modula-3 threading library is a thin wrapper over pthreads. Whatever level of concurrency your kernel and hardware can provide, the Modula-3 runtime will provide. (There is a non-default user-thread *option* for which the answer is "no", but it is not currently implemented on Linux/amd64 and doesn't work currently on any Linux. So again, definitely yes.) - Jay ---------------------------------------- > To: m3devel at elegosoft.com > From: mfmorss at aep.com > Date: Mon, 16 Mar 2009 14:33:13 -0400 > Subject: [M3devel] CM3 on Linux 64-bit > > I apologize in advance if this is not the right place to ask this. If I > use CM3 on Linux 64-bit running on Intel multi-core chips (two quad core > chips, actually), do I have a valid expectation that I will be able to > implement concurrent multithreading? > > I tried to discover this on the website, and if it's there, I must have > missed it. > > Thanks in advance. From jay.krell at cornell.edu Mon Mar 16 21:55:58 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 20:55:58 +0000 Subject: [M3devel] recent problems? In-Reply-To: References: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> Message-ID: It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > From dabenavidesd at yahoo.es Tue Mar 17 01:14:35 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 16 Mar 2009 17:14:35 -0700 (PDT) Subject: [M3devel] recent problems? In-Reply-To: Message-ID: <434202.9613.qm@web24705.mail.ird.yahoo.com> Hi all: well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system. Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time. So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler). I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here. But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did? Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said. Thanks in advance --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: Re: [M3devel] recent problems? Para: "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 3:55 It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at .../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 17 03:47:10 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 02:47:10 +0000 Subject: [M3devel] recent problems? In-Reply-To: <434202.9613.qm@web24705.mail.ird.yahoo.com> References: <434202.9613.qm@web24705.mail.ird.yahoo.com> Message-ID: I'm making the system more safe, not less. The previous methodology was tedious, error prone, and didn't get any sort of checking. Whatever was declared in the *.i3 files was presumed correct. The linkage from the next layer to this layer gets the same amount of checking as it used. The link you point to shows people fixing things the same way as I am making them. unix/*.i3 must use <*EXTERNAL*> to declare C functions. That is what it did. That is what it does. Extend this out slightly to m3core/libm3. Same thing. The difference is whether or not those C functions are implemented right there, once, plain to see that they match the <*EXTERNAL*> declarations, or whether they are in a per-platform /usr/include and source tree somewhere, with tedious and error prone and per-platform verification as to if they are correct. As well as copy/pasting where there the "API" might be a macro. Really, I am making the system more safe, not less. There is no loss in checking but there is more obvious correctness by human inspection in what must be unsafe, one way or another. The result is also more portable. - Jay Date: Mon, 16 Mar 2009 17:14:35 -0700 From: dabenavidesd at yahoo.es To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] recent problems? Hi all: well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system. Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time. So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler). I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here. But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did? Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said. Thanks in advance --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: Re: [M3devel] recent problems? Para: "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 3:55 It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Mar 17 04:05:24 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 16 Mar 2009 20:05:24 -0700 (PDT) Subject: [M3devel] recent problems? In-Reply-To: Message-ID: <423325.54448.qm@web24703.mail.ird.yahoo.com> The problem is not your changes, the problem is that putting C code can't be checked by a type safe checking process: I do agree the goodness of your checks, which may get things better, but unfortunately you have seen the effects of the this changes, we can't have human checking to solve unhidden bugs. Compile type checking allows to discard problems in Modula-3 code and at least? a clue that something needs more checking in UNSAFE Modules or Interfaces. You have changed that we depend no more on cloned platform dependent .i3 files, but on C code which it slef depends on unsafe C platform dependent thirdparty libraries. That is the problem is not now on the Modula-3 source code but in the actual platform. I can't agree that is safer than it was before, nor because of the language, or you, but of the thid party code. Now we have more code just that it's no more Modula-3, it's C but yes, is lesser code (well forgeting about C preprocessor). I hope this is more clear of my ideas and any clue of what i am tryin to say here. Thanks for your comments. --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: RE: [M3devel] recent problems? Para: "Daniel (M3)" , "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 9:47 #yiv878206134 .hmmessage P { margin:0px;padding:0px;} #yiv878206134 { font-size:10pt;font-family:Verdana;} I'm making the system more safe, not less. ? ? The previous methodology was tedious, error prone, and didn't get any sort of checking. ? ? Whatever was declared in the *.i3 files was presumed correct. ? ? The linkage from the next layer to this layer gets the same amount of checking as it used. ? ? The link you point to shows people fixing things the same way as I am making them. ? ? unix/*.i3 must use <*EXTERNAL*> to declare C functions. That is what it did. That is what it does. Extend this out slightly to m3core/libm3. ?Same thing. The difference is whether or not those C functions are implemented right there, once, plain to see that they match the <*EXTERNAL*> declarations, or whether they are in a per-platform /usr/include and source tree somewhere, with tedious and error prone and per-platform verification as to if they are correct. As well as copy/pasting where there the "API" might be a macro. ? ? Really, I am making the system more safe, not less. There is no loss in checking but there is more obvious correctness by human inspection in what must be unsafe, one way or another. ? ? The result is also more portable. ? ? ?- Jay ? Date: Mon, 16 Mar 2009 17:14:35 -0700 From: dabenavidesd at yahoo.es To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] recent problems? Hi all: well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system. Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time. So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler). I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here. But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus..blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did? Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said. Thanks in advance --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: Re: [M3devel] recent problems? Para: "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 3:55 It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at .../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Mar 17 04:30:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 17 Mar 2009 14:30:35 +1100 Subject: [M3devel] recent problems? In-Reply-To: References: <434202.9613.qm@web24705.mail.ird.yahoo.com> Message-ID: Keep up the good work Jay! On 17 Mar 2009, at 13:47, Jay wrote: > I'm making the system more safe, not less. > > > The previous methodology was tedious, error prone, and didn't get > any sort of checking. > > > Whatever was declared in the *.i3 files was presumed correct. > > > The linkage from the next layer to this layer gets the same amount > of checking as it used. > > > The link you point to shows people fixing things the same way as I > am making them. > > > unix/*.i3 must use <*EXTERNAL*> to declare C functions. > That is what it did. That is what it does. > Extend this out slightly to m3core/libm3. > Same thing. > The difference is whether or not those C functions are implemented > right there, once, plain to see that they match the <*EXTERNAL*> > declarations, or whether they are in a per-platform /usr/include and > source tree somewhere, with tedious and error prone and per-platform > verification as to if they are correct. As well as copy/pasting > where there the "API" might be a macro. > > > Really, I am making the system more safe, not less. > There is no loss in checking but there is more obvious correctness > by human inspection in what must be unsafe, one way or another. > > > The result is also more portable. > > > - Jay > > Date: Mon, 16 Mar 2009 17:14:35 -0700 > From: dabenavidesd at yahoo.es > To: hosking at cs.purdue.edu; jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > Hi all: > well, I know more about the kind of work done recently, which I can > not just say is unsafe, but putting a layer of C code that obviously > is dependent of each Linux/Unix, I guess in the past this is not > always true, but having each Linux it's own headers and different > implementations makes more unstable the system. > Besides the type checking made by C Compiler is not checked at link > time, in contrast of Modula-3 that type checks whenever interfaces > are changed and checks on link time. > So if you put change in your C code doesn't mean that Modula-3 will > catch common silly but common true errors, like buffer overflows > that if not checked at run time will crash (almost always) at > runtime of a safe program, and it will not be safe (hidden code is > beyond the Modula-3 compiler). > I strongly support simplifying and factoring as much as possible, > but try to use what is there in Modula-3, not re-implementing in > another Language if possible at all. I know but even more, the idea > of having linking with C code on the kernel system calls allows to > protect from so called side effects of Kernel code. Memory > protection is exhausted here. > But when using true library user space system calls, this puts in a > dangerous side the untrusted code. Here I reclaim again not using > more that true system calls. I see that this started to be harder > with AMD64 or x86_64 current platforms, so further development may > be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html > about ezm3 related problems, is this supposed to be handled in Cm3 > like the same they did? > Jay and all seem to do the better job they can, but I don't want to > miss the opportunity to say this if I may. I will tell you later > more about the type system If this it is useful to be said. > > Thanks in advance > > --- El lun, 16/3/09, Jay escribi?: > De: Jay > Asunto: Re: [M3devel] recent problems? > Para: "Tony" > CC: "m3devel" > Fecha: lunes, 16 marzo, 2009 3:55 > > It's ok on LINUXLIBC6 with the "new headers" but > I believe PPC_DARWIN problem caused by them so > backed out pending debugging. > This one looks easy to solve, though my time > is scarser next week or two. > > I should have maybe considered: > "new headers" used on a number of Linux systems already > but no Darwin systems yet > > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Tue, 17 Mar 2009 01:54:34 +1100 > > CC: > m3devel at elegosoft.com > > Subject: Re: [M3devel] recent problems? > > > > This is worrying as it seems some level of instability has been > > introduced by recent changes. mentor used to be fine. > > > > On 17 Mar 2009, at 00:16, Jay wrote: > > > >> > >> mklib seems ok now, having started over with a new checkout, new > >> build. > >> Strange considering what I had already tried, this problem had been > >> plaguing me over a week. > >> > >> > >> stubgen doesn't hang with 1.5, will try 1.7 again/later. > >> > >> > >> But formsedit still crashes during startup intermittently, > >> and Cygwin X apps hang at startup. > >> ugh. > >> I know, I probably caused whatever problem.. > >> > >> > >> - Jay > >> > >> > >> > >> ---------------------------------------- > >>> From: > jay.krell at cornell.edu > >>> To: hosking at cs.purdue.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: RE: [M3devel] recent problems? > >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 > >>> > >>> > >>> Thanks. > >>> > >>> > >>> Here is another one. > >>> I found this testing moving PPC_DARWIN to "my headers". > >>> formsedit crashes during startup roughly more than > >>> half the times I start up, but not every time. > >>> The stack is always the same. > >>> I'll test it without my change. > >>> I think it'll happen either way, but I'll see. > >>> Yes, it recurs without my change, though I double > >>> check that my change is really undone. > >>> I'll have to dig into this. > >>> > >>> > >>> How does one get the code from CVS corresponding to a > date? > >>> cvs upd -D ? > >>> I'll try that or something, see if I can find when things > worked. > >>> > >>> > >>> I should also be able to try the mklib crashing scenario > >>> on other platforms. It normally doesn't run on other > platforms. > >>> > >>> > >>> stubgen..if I'm ambitious, I can run in a loop on another > platform. > >>> But I think just moving Cygwin off of pthreads will > "fix" it > >>> and provide a cleaner base (not due to pthreads, but the Cygwin > >>> stuff). > >>> > >>> > >>> Program received signal EXC_BAD_ACCESS, Could not access memory. > >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 > >>> [Switching to process 19583 thread 0x2643] > >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows > >>> (M3_Ao3CED_v=0x1f1eef4) at > ../src/lego/POSIX/Sc > >>> rollerVBTClass.m3:325 > >>> 325 VBT.PaintTint(v, r, v.shadow.bg); > >>> (gdb) bt > >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows > >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI > >>> X/ScrollerVBTClass.m3:325 > >>> #1 0x0031766c in ScrollerVBTClass__PaintView > >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV > >>> BTClass.m3:292 > >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, > >>> M3_A0Kbc5_rgn=0xf0284778) at ../ > >>> src/lego/POSIX/ScrollerVBTClass.m3:693 > >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay > >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV > >>> BTClass.m3:706 > >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at > ../ > >>> src/vbt/VBTClass.m3:367 > >>> > #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 > >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ > >>> VBTRep.m3:601 > >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ > >>> src/vbt/VBTRep.m3:606 > >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) > >>> at ../src/thread/PTHREAD/ThreadP > >>> Thread.m3:531 > >>> #9 0x0132fb58 in ThreadPThread__ThreadBase > >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr > >>> eadPThread.m3:508 > >>> #10 0x9002b908 in _pthread_body () > >>> (gdb) > >>> > >>> > >>> > >>> - Jay > >>> > >>> > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> To: > jay.krell at cornell.edu > >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] recent problems? > >>>> > >>>> You might have structure sizes wrong and your stack will get > shifted > >>>> around as the command line changes length. You get some data > in a > >>>> structure wrong and then hit the wrong stack org and you might > see > >>>> problems like this. > >>>> > >>>> I am not running things totally off of the head, so if the > problem > >>>> was > >>>> introduced recently it might only now be seen. > >>>> > >>>> On 16 Mar 2009, at 06:15, Jay wrote: > >>>> > >>>>> > >>>>> I'm seeing some problems lately. Maybe it is just me. > >>>>> Some of them I've had over > a week (ie: before my > (most) recent > >>>>> changes), > >>>>> some of them even if recently appeared I verified without > my (most) > >>>>> recent changes. > >>>>> > >>>>> On Cygwin 1.5, mklib always crashes. I haven't been > able to debug > >>>>> it. > >>>>> This has been over a week. > >>>>> I've had to stop using Cygwin for Modula-3 development > on this > >>>>> machine. > >>>>> I have a good repro but hadn't had luck yet debugging > it. > >>>>> Basically if I shorten the mklib command line (in the > response > >>>>> file) substantially, no crash. > >>>>> There is a cut off somewhere. > >>>>> > >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but > not always > >>>>> > hangs. > >>>>> It hangs nowhere else. > >>>>> This I verified occured without my recent changes. > >>>>> I only just in the past few days tried Cygwin 1.7. > >>>>> mklib works fine here. > >>>>> Of course since this is somewhat intermittent, maybe it > isn't a new > >>>>> problem. > >>>>> > >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine > each, separate > >>>>> machines, > >>>>> though they do coexist ok on one machine. > >>>>> 1.7 seemed much faster (on an unimpressive machine), > though 1.7 > >>>>> binares > >>>>> apparently don't run on 1.5 -- at least not if they > use assert(). > >>>>> 1.7 is a recent past or future release, a long time in the > works, > >>>>> drops Win9x support, lots of good > sounding changes. > >>>>> > >>>>> I should run m3tests more, maybe they will reveal the > crash or the > >>>>> hang as well. > >>>>> > >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least > in one > >>>>> directory. > >>>>> But I think this stopped happening. > >>>>> > >>>>> Cygwin being broken pushes me to other platforms more, > probably a > >>>>> good thing. > >>>>> I'm loathe to debug the hang. When it occurs I > can't see any stacks > >>>>> in gdb. I can see in strace.. > >>>>> I think we are waiting for all the threads to suspend > themselves. > >>>>> I'll probably try moving back to Win32 threads and see > if it clears > >>>>> up. > >>>>> I know that's not > great. > >>>>> There isn't a clear implied question and I know I > should/need to > >>>>> look into these, > >>>>> but I also thought I shouldn't keep this to myself. I > also > >>>>> understand the philosophy > >>>>> of stopping changes when there are problems, to stop > further > >>>>> damage, but, of course, > >>>>> I'm very confident in my changes (always..), have been > testing them > >>>>> on other platforms, > >>>>> and looking them over extra extra since I know of these > other > >>>>> problems. > >>>>> > >>>>> I'm not sure any problem on Cygwin is worrisome > really. > >>>>> I think the underlying code is kind of gnarly and I > don't think > >>>>> anyone uses this platform, though people asked for > it. > >>>>> But I did have a crash on LINUXLIBC6. > >>>>> > >>>>> - Jay > >>>> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 17 08:10:35 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 07:10:35 +0000 Subject: [M3devel] recent problems? In-Reply-To: <423325.54448.qm@web24703.mail.ird.yahoo.com> References: <423325.54448.qm@web24703.mail.ird.yahoo.com> Message-ID: Daniel, I do not understand. We were already depending on the underlying code. Now we also have thin C wrappers and a little of checking by the C compiler. Where before we had no checking. I will admit I feel little hesitation to add more C code. I am really fluent and comfortable in C and am well aware of its dangers and how to avoid them. But..well..I need more justification than "because I can". I should add, btw, that that link suggests going a little beyond what I have done. I have a few ad-hoc methodologies/goals. Mainly "remove structs" and "remove constant #defines" (or wrap them). However, "remove all types" is not a goal. int remains, among others. Where there is something "as simple as" int foo(int); I have held back and just left the direct: <*EXTERNAL*> PROCEDURE foo(int):int; however that link suggests that /everything/ should be wrapped. It is easy to do, just: Interface.i3 <*EXTERNAL Interface__Foo*> PROCEDURE foo(int):int: Interface.c: int Interface__Foo(int a) { return Foo(a); } Usually this does nothing but introduce a jmp or an unoptimized prolog/call/epilog. (It can also help in getting callstacks and debugging, though that is a flawed argument.) However if foo is a macro, or some fancy inline function (more common these days), it could be a useful transform. (Look at how stat works..) I am interested in what people think here -- on the idea of "wrapping everything". There isn't a lot of this stuff left, so maybe we should go ahead and wrap it. Hey, actually, this will help with the "remains" -- the time stuff esp. I can hardcode time_t et. al. as long and go through thin wrappers. Sometimes I strive to wrap at a higher level, but that isn't necessary. This might be what you are alluding to, and has been on my mind a while anyway; I am sympathetic to the idea of eliminating C runtime dependencies and making direct kernel calls, at least on Linux. It is common on Linux/ARM systems to have uclibc instead of glibc. glibc is deemed "bloated" in some circles. Our binaries were not and are not portable to these systems. If we don't make this change, we are headed toward platforms that are more than architecture_kernel and instead architecture_kernel_cruntime -- ARM_LINUX_GLIBC, ARM_LINUX_UCLIBC, but it's worse than actually, ARM_LINUX_OLDABI_GLIBC, ARM_LINUX_OLDABI_UCLIBC, ARM_LINUX_UCLIBC, ARM_LINUX_GLIBC. I'd like to imagine "oldabi" is old and irrelevant, but I have such a system -- oldabi/uclibc -- the Western Digital MyBook "World Edition" is a viable target for Modula-3, on my list..though things are advancing..I have an $80 PogoPlug on the way, it might be much more performant..also, you could probably statically link to "any" C runtime, given our light usage.. "dietlibc" is another option, though I had trouble using it..and it seems a little too non-mainstream for me. "newlib" is also an option. But: This kind of devolves to: "Hey Tony, can you look into the Linux kernel 'futex' and 'clone' stuff et. al. and implement the Modula-3 threading library on top of it?" (Or anyone else?) That's not the whole story though. There'd still be stat, open, and socket stuff. But I think threading the main difficulty. I'm pretty sure this viable -- that the Modula-3 runtime is "thick enough", that anyone who maintains it (Tony; not necessarily me) is capable of implementing reasonable threading "on top of almost anything". - Jay Date: Mon, 16 Mar 2009 20:05:24 -0700 From: dabenavidesd at yahoo.es Subject: RE: [M3devel] recent problems? To: hosking at cs.purdue.edu; jay.krell at CORNELL.EDU CC: m3devel at elegosoft.com The problem is not your changes, the problem is that putting C code can't be checked by a type safe checking process: I do agree the goodness of your checks, which may get things better, but unfortunately you have seen the effects of the this changes, we can't have human checking to solve unhidden bugs. Compile type checking allows to discard problems in Modula-3 code and at least a clue that something needs more checking in UNSAFE Modules or Interfaces. You have changed that we depend no more on cloned platform dependent .i3 files, but on C code which it slef depends on unsafe C platform dependent thirdparty libraries. That is the problem is not now on the Modula-3 source code but in the actual platform. I can't agree that is safer than it was before, nor because of the language, or you, but of the thid party code. Now we have more code just that it's no more Modula-3, it's C but yes, is lesser code (well forgeting about C preprocessor). I hope this is more clear of my ideas and any clue of what i am tryin to say here. Thanks for your comments. --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: RE: [M3devel] recent problems? Para: "Daniel (M3)" , "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 9:47 I'm making the system more safe, not less. The previous methodology was tedious, error prone, and didn't get any sort of checking. Whatever was declared in the *.i3 files was presumed correct. The linkage from the next layer to this layer gets the same amount of checking as it used. The link you point to shows people fixing things the same way as I am making them. unix/*.i3 must use <*EXTERNAL*> to declare C functions. That is what it did. That is what it does. Extend this out slightly to m3core/libm3. Same thing. The difference is whether or not those C functions are implemented right there, once, plain to see that they match the <*EXTERNAL*> declarations, or whether they are in a per-platform /usr/include and source tree somewhere, with tedious and error prone and per-platform verification as to if they are correct. As well as copy/pasting where there the "API" might be a macro. Really, I am making the system more safe, not less. There is no loss in checking but there is more obvious correctness by human inspection in what must be unsafe, one way or another. The result is also more portable. - Jay Date: Mon, 16 Mar 2009 17:14:35 -0700 From: dabenavidesd at yahoo.es To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] recent problems? Hi all: well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system. Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time. So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler). I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here. But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did? Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said. Thanks in advance --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: Re: [M3devel] recent problems? Para: "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 3:55 It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone.. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 17 08:22:50 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 07:22:50 +0000 Subject: [M3devel] recent problems? In-Reply-To: <423325.54448.qm@web24703.mail.ird.yahoo.com> References: <423325.54448.qm@web24703.mail.ird.yahoo.com> Message-ID: Truncated again. Maybe a good thing. (But do try to wade through, there are a few "new questions" -- 1) that link suggests going further with the wrapping. What do folks think? There's so little left to do, and it would provide a little value, so I am sympathetic to it..but it should probably be automated, now that I think about the actual volume 2) Tony, can you implement Modua-3 on top of Linux kernel futex/clone? That might address Daniel's point, and give us portability across C runtimes, such as Linux/ARM/uclibc and Linux/ARM/glibc; I have a Linux/ARM/uclibc system.). Daniel, ok, is the choice: "some code with no checking" vs. "more code with a little checking" and, depending on "more vs. some". and "no vs. little", you could argue that "some with no" is better? Agreed, it's simple math, but I think in this case we are better with "more code with a little checking". "It depends on the coefficients." Again, I am confident in my C programming..having written thousands of lines in the past few months.. - Jay From: jay.krell at cornell.edu To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] recent problems? Date: Tue, 17 Mar 2009 07:10:35 +0000 Daniel, I do not understand. We were already depending on the underlying code. Now we also have thin C wrappers and a little of checking by the C compiler. Where before we had no checking. I will admit I feel little hesitation to add more C code. I am really fluent and comfortable in C and am well aware of its dangers and how to avoid them. But..well..I need more justification than "because I can". I should add, btw, that that link suggests going a little beyond what I have done. I have a few ad-hoc methodologies/goals. Mainly "remove structs" and "remove constant #defines" (or wrap them). However, "remove all types" is not a goal. int remains, among others. Where there is something "as simple as" int foo(int); I have held back and just left the direct: <*EXTERNAL*> PROCEDURE foo(int):int; however that link suggests that /everything/ should be wrapped. It is easy to do, just: Interface.i3 <*EXTERNAL Interface__Foo*> PROCEDURE foo(int):int: Interface.c: int Interface__Foo(int a) { return Foo(a); } Usually this does nothing but introduce a jmp or an unoptimized prolog/call/epilog. (It can also help in getting callstacks and debugging, though that is a flawed argument.) However if foo is a macro, or some fancy inline function (more common these days), it could be a useful transform. (Look at how stat works..) I am interested in what people think here -- on the idea of "wrapping everything". There isn't a lot of this stuff left, so maybe we should go ahead and wrap it. Hey, actually, this will help with the "remains" -- the time stuff esp. I can hardcode time_t et. al. as long and go through thin wrappers. Sometimes I strive to wrap at a higher level, but that isn't necessary. This might be what you are alluding to, and has been on my mind a while anyway; I am sympathetic to the idea of eliminating C runtime dependencies and making direct kernel calls, at least on Linux. It is common on Linux/ARM systems to have uclibc instead of glibc. glibc is deemed "bloated" in some circles. Our binaries were not and are not portable to these systems. If we don't make this change, we are headed toward platforms that are more than architecture_kernel and instead architecture_kernel_cruntime -- ARM_LINUX_GLIBC, ARM_LINUX_UCLIBC, but it's worse than actually, ARM_LINUX_OLDABI_GLIBC, ARM_LINUX_OLDABI_UCLIBC, ARM_LINUX_UCLIBC, ARM_LINUX_GLIBC. I'd like to imagine "oldabi" is old and irrelevant, but I have such a system -- oldabi/uclibc -- the Western Digital MyBook "World Edition" is a viable target for Modula-3, on my list..though things are advancing..I have an $80 PogoPlug on the way, it might be much more performant..also, you could probably statically link to "any" C runtime, given our light usage.. "dietlibc" is another option, though I had trouble using it..and it seems a little too non-mainstream for me. "newlib" is also an option. But: This kind of devolves to: "Hey Tony, can you look into the Linux kernel 'futex' and 'clone' stuff et. al. and implement the Modula-3 threading library on top of it?" (Or anyone else?) That's not the whole story though. There'd still be stat, open, and socket stuff. But I think threading the main difficulty. I'm pretty sure this viable -- that the Modula-3 runtime is "thick enough", that anyone who maintains it (Tony; not necessarily me) is capable of implementing reasonable threading "on top of almost anything". - Jay Date: Mon, 16 Mar 2009 20:05:24 -0700 From: dabenavidesd at yahoo.es Subject: RE: [M3devel] recent problems? To: hosking at cs.purdue.edu; jay.krell at CORNELL.EDU CC: m3devel at elegosoft.com The problem is not your changes, the problem is that putting C code can't be checked by a type safe checking process: I do agree the goodness of your checks, which may get things better, but unfortunately you have seen the effects of the this changes, we can't have human checking to solve unhidden bugs. Compile type checking allows to discard problems in Modula-3 code and at least a clue that something needs more checking in UNSAFE Modules or Interfaces. You have changed that we depend no more on cloned platform dependent .i3 files, but on C code which it slef depends on unsafe C platform dependent thirdparty libraries. That is the problem is not now on the Modula-3 source code but in the actual platform. I can't agree that is safer than it was before, nor because of the language, or you, but of the thid party code. Now we have more code just that it's no more Modula-3, it's C but yes, is lesser code (well forgeting about C preprocessor). I hope this is more clear of my ideas and any clue of what i am tryin to say here. Thanks for your comments. --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: RE: [M3devel] recent problems? Para: "Daniel (M3)" , "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 9:47 I'm making the system more safe, not less. The previous methodology was tedious, error prone, and didn't get any sort of checking. Whatever was declared in the *.i3 files was presumed correct. The linkage from the next layer to this layer gets the same amount of checking as it used. The link you point to shows people fixing things the same way as I am making them. unix/*.i3 must use <*EXTERNAL*> to declare C functions. That is what it did. That is what it does. Extend this out slightly to m3core/libm3. Same thing. The difference is whether or not those C functions are implemented right there, once, plain to see that they match the <*EXTERNAL*> declarations, or whether they are in a per-platform /usr/include and source tree somewhere, with tedious and error prone and per-platform verification as to if they are correct. As well as copy/pasting where there the "API" might be a macro. Really, I am making the system more safe, not less. There is no loss in checking but there is more obvious correctness by human inspection in what must be unsafe, one way or another. The result is also more portable. - Jay Date: Mon, 16 Mar 2009 17:14:35 -0700 From: dabenavidesd at yahoo.es To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] recent problems? Hi all: well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system. Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time. So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler). I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here. But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did? Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said. Thanks in advance --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: Re: [M3devel] recent problems? Para: "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 3:55 It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone.. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 17 08:32:54 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 07:32:54 +0000 Subject: [M3devel] FW: recent problems? In-Reply-To: <423325.54448.qm@web24703.mail.ird.yahoo.com> References: <423325.54448.qm@web24703.mail.ird.yahoo.com> Message-ID: [truncated again, I should have known -- need to forward instead of replyall] From: jay.krell at cornell.edu To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] recent problems? Date: Tue, 17 Mar 2009 07:22:50 +0000 Truncated again. Maybe a good thing. (But do try to wade through, there are a few "new questions" -- 1) that link suggests going further with the wrapping. What do folks think? There's so little left to do, and it would provide a little value, so I am sympathetic to it..but it should probably be automated, now that I think about the actual volume 2) Tony, can you implement Modua-3 on top of Linux kernel futex/clone? That might address Daniel's point, and give us portability across C runtimes, such as Linux/ARM/uclibc and Linux/ARM/glibc; I have a Linux/ARM/uclibc system.). Daniel, ok, is the choice: "some code with no checking" vs. "more code with a little checking" and, depending on "more vs. some". and "no vs. little", you could argue that "some with no" is better? Agreed, it's simple math, but I think in this case we are better with "more code with a little checking". "It depends on the coefficients." Again, I am confident in my C programming..having written thousands of lines in the past few months.. - Jay From: jay.krell at cornell.edu To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] recent problems? Date: Tue, 17 Mar 2009 07:10:35 +0000 Daniel, I do not understand. We were already depending on the underlying code. Now we also have thin C wrappers and a little of checking by the C compiler. Where before we had no checking. I will admit I feel little hesitation to add more C code. I am really fluent and comfortable in C and am well aware of its dangers and how to avoid them. But..well..I need more justification than "because I can". I should add, btw, that that link suggests going a little beyond what I have done. I have a few ad-hoc methodologies/goals. Mainly "remove structs" and "remove constant #defines" (or wrap them). However, "remove all types" is not a goal. int remains, among others. Where there is something "as simple as" int foo(int); I have held back and just left the direct: <*EXTERNAL*> PROCEDURE foo(int):int; however that link suggests that /everything/ should be wrapped. It is easy to do, just: Interface.i3 <*EXTERNAL Interface__Foo*> PROCEDURE foo(int):int: Interface.c: int Interface__Foo(int a) { return Foo(a); } Usually this does nothing but introduce a jmp or an unoptimized prolog/call/epilog. (It can also help in getting callstacks and debugging, though that is a flawed argument.) However if foo is a macro, or some fancy inline function (more common these days), it could be a useful transform. (Look at how stat works..) I am interested in what people think here -- on the idea of "wrapping everything". There isn't a lot of this stuff left, so maybe we should go ahead and wrap it. Hey, actually, this will help with the "remains" -- the time stuff esp. I can hardcode time_t et. al. as long and go through thin wrappers. Sometimes I strive to wrap at a higher level, but that isn't necessary. This might be what you are alluding to, and has been on my mind a while anyway; I am sympathetic to the idea of eliminating C runtime dependencies and making direct kernel calls, at least on Linux. It is common on Linux/ARM systems to have uclibc instead of glibc. glibc is deemed "bloated" in some circles. Our binaries were not and are not portable to these systems. If we don't make this change, we are headed toward platforms that are more than architecture_kernel and instead architecture_kernel_cruntime -- ARM_LINUX_GLIBC, ARM_LINUX_UCLIBC, but it's worse than actually, ARM_LINUX_OLDABI_GLIBC, ARM_LINUX_OLDABI_UCLIBC, ARM_LINUX_UCLIBC, ARM_LINUX_GLIBC. I'd like to imagine "oldabi" is old and irrelevant, but I have such a system -- oldabi/uclibc -- the Western Digital MyBook "World Edition" is a viable target for Modula-3, on my list..though things are advancing..I have an $80 PogoPlug on the way, it might be much more performant..also, you could probably statically link to "any" C runtime, given our light usage.. "dietlibc" is another option, though I had trouble using it..and it seems a little too non-mainstream for me. "newlib" is also an option. But: This kind of devolves to: "Hey Tony, can you look into the Linux kernel 'futex' and 'clone' stuff et. al. and implement the Modula-3 threading library on top of it?" (Or anyone else?) That's not the whole story though. There'd still be stat, open, and socket stuff. But I think threading the main difficulty. I'm pretty sure this viable -- that the Modula-3 runtime is "thick enough", that anyone who maintains it (Tony; not necessarily me) is capable of implementing reasonable threading "on top of almost anything". - Jay Date: Mon, 16 Mar 2009 20:05:24 -0700 From: dabenavidesd at yahoo.es Subject: RE: [M3devel] recent problems? To: hosking at cs.purdue.edu; jay.krell at CORNELL.EDU CC: m3devel at elegosoft.com The problem is not your changes, the problem is that putting C code can't be checked by a type safe checking process: I do agree the goodness of your checks, which may get things better, but unfortunately you have seen the effects of the this changes, we can't have human checking to solve unhidden bugs. Compile type checking allows to discard problems in Modula-3 code and at least a clue that something needs more checking in UNSAFE Modules or Interfaces. You have changed that we depend no more on cloned platform dependent .i3 files, but on C code which it slef depends on unsafe C platform dependent thirdparty libraries. That is the problem is not now on the Modula-3 source code but in the actual platform. I can't agree that is safer than it was before, nor because of the language, or you, but of the thid party code. Now we have more code just that it's no more Modula-3, it's C but yes, is lesser code (well forgeting about C preprocessor). I hope this is more clear of my ideas and any clue of what i am tryin to say here. Thanks for your comments. --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: RE: [M3devel] recent problems? Para: "Daniel (M3)" , "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 9:47 I'm making the system more safe, not less. The previous methodology was tedious, error prone, and didn't get any sort of checking. Whatever was declared in the *.i3 files was presumed correct. The linkage from the next layer to this layer gets the same amount of checking as it used. The link you point to shows people fixing things the same way as I am making them. unix/*.i3 must use <*EXTERNAL*> to declare C functions. That is what it did. That is what it does. Extend this out slightly to m3core/libm3. Same thing. The difference is whether or not those C functions are implemented right there, once, plain to see that they match the <*EXTERNAL*> declarations, or whether they are in a per-platform /usr/include and source tree somewhere, with tedious and error prone and per-platform verification as to if they are correct. As well as copy/pasting where there the "API" might be a macro. Really, I am making the system more safe, not less. There is no loss in checking but there is more obvious correctness by human inspection in what must be unsafe, one way or another. The result is also more portable. - Jay Date: Mon, 16 Mar 2009 17:14:35 -0700 From: dabenavidesd at yahoo.es To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] recent problems? Hi all: well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system. Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time. So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler). I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here. But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did? Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said. Thanks in advance --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: Re: [M3devel] recent problems? Para: "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 3:55 It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone.. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 17 08:42:48 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 07:42:48 +0000 Subject: [M3devel] off topic: buy an Alpha? Message-ID: mailing list abuse: Anyone want to buy any Alphas? I might be stuck with 5 but I'd really just want one. They are a 1U model, which I think is the ideal size (short of a laptop or something smaller). You know, for porting to ALPHA_LINUX ALPHA_FREEBSD ALPHA_NETBSD ALPHA_OPENBSD ALPHA_VMS ALPHA_TRU64 ALPHA_NT ?? :) ? I wouldn't make money here, just save myself the space and expense. $200 each plus shipping ($20??). http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&Item=230329596443 Item 230329596443 on eBay. 1gig ram, 30gig drive, 600MHz, single proc no optical drive -- I'd use an external SCSI drive. I'd be willing to [try to] setup any of the first 4 operating systems and send it on. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 17 10:02:44 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 09:02:44 +0000 Subject: [M3devel] socket linger? Message-ID: Can someone please weight on this? I think these two chunks should be identical, though not sure which way they should go. C:\dev2\cm3\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(472): linger := Usocket.struct_linger{1, 1}; C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\SocketWin32.m3(429): linger := WinSock.struct_linger{0, 0}; This is the same as version #1 in the elegosoft history. I haven't checked 3.6. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Mar 17 10:10:11 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 17 Mar 2009 02:10:11 -0700 Subject: [M3devel] socket linger? In-Reply-To: Your message of "Tue, 17 Mar 2009 09:02:44 -0000." Message-ID: <200903170910.n2H9ABm4032328@camembert.async.caltech.edu> Hi Jay, All I can say about this is that one of the things that I have found different about Modula-3 on Unix and Windows is that there are what seems to be some quite serious bugs in the TCP stack on Windows 2000 (and probably earlier versions of NT). They have to do with buffering and buffer sizes. I wouldn't be surprised if fiddling with "linger" is some sort of workaround. (I don't think the linger difference could cause the bug; I think the bug is in the NT kernel.) I don't remember the details but it has something to do with attempting to send or receive a very large amount of data in a single system call on a fast link. Mika Jay writes: >--_ec278f1c-d155-41e4-8856-bb89662f7cd6_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Can someone please weight on this? > >I think these two chunks should be identical=2C though not sure which way t= >hey should go. > >=20 > >=20 > >C:\dev2\cm3\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(472): linger :=3D = >Usocket.struct_linger{1=2C 1}=3B >C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\SocketWin32.m3(429): linger :=3D = >WinSock.struct_linger{0=2C 0}=3B > > >This is the same as version #1 in the elegosoft history. > >I haven't checked 3.6. > >=20 > > - Jay > > > > > > >--_ec278f1c-d155-41e4-8856-bb89662f7cd6_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Can someone please weight on this?
>I think these two chunks should be identical=2C though not sure which way t= >hey should go.
> =3B
> =3B
>C:\dev2\cm3\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(472): =3B =3B= > =3B linger :=3D Usocket.struct_linger{1=2C 1}=3B
C:\dev2\cm3\m3-lib= >s\libm3\src\os\WIN32\SocketWin32.m3(429): =3B =3B =3B linger := >=3D WinSock.struct_linger{0=2C 0}=3B

>This is the same as version #1 in the elegosoft history.
>I haven't checked 3.6.
> =3B
> =3B- Jay





>= > >--_ec278f1c-d155-41e4-8856-bb89662f7cd6_-- From jay.krell at cornell.edu Tue Mar 17 12:51:00 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 11:51:00 +0000 Subject: [M3devel] FW: Usocket.get/setsockopt needs wrappers? In-Reply-To: <20090317112837.DEF3810D6076@birch.elegosoft.com> References: <20090317112837.DEF3810D6076@birch.elegosoft.com> Message-ID: Um...I suggest there should be a type-safe C layer for the various get/setsockopt uses? All this use of ADR and BYTESIZE in the Modula-3 code seems questionable. Yes, I know that Modula-3 is great because it is a systems programming language in which you can do these things. Actually, if the C interface takes void*, it does, then might as well write the type-safe layer in Modula-3. (That is, the C layer wouldn't get any checking.) UsocketOpt.SetLinger(onoff:boolean, timeout:int); UsocketOpt.SetTcpNoDelay(boolean) UsocketOpt.SetSendBufferSize(INTEGER) UsocketOpt.SetRecieveBufferSize(INTEGER); UsocketOpt.SetKeepAlive(BOOLEAN) ? I would implement SetLinger in C, since it uses a struct, but the rest I think all are specified as using int so Modula-3 ok. There is other type-unsafety in Usocket that should probably be wrapped. I don't know, not sure type safety is worth writing all the wrappers, or if everyone gets it right anyway. It looks one of the NoDelay cases is wrong for 64 bit big endian systems. - Jay ---------------------------------------- > Date: Tue, 17 Mar 2009 12:28:37 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/03/17 12:28:37 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Usocket.i3 m3makefile > cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/darwin-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/netbsd-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3 > > Log message: > multi-part experiment > > 1: wrap everything > 2: wrap everything taking input socklen_t > 3: wrap everything taking input/output socklen_t > > Result is removal of platform-specific socklen_t. > But at the cost of 200 lines of C (though really > #1 has nothing to do with socklen_t, #2 is > /perhaps/ optional, #3 is the real part), perhaps > this is not worthwhile. I could argue the 200 > lines are simple and not dense, but "lines are lines"? > Also, this approach is definitely tedious and therefore > error-prone. > > socklen_t so far is 32 bit unsigned everywhere except: > signed on Cygwin > size_t on HP-UX, therefore 64 bits on PA64_HPUX/IA64_HPUX > > There is something fishy going on in that it seems > folks were in places passing ADR(INTEGER) here, which > should fail to compile on everything but Cygwin, esp. > 64 bit platforms. Could be that subranges don't > define different types in this context? > UNTRACED REF BITS 32 FOR [0..1] > same type as UNTRACED REF BITS 32 FOR [0..2]? > > I was considering making changes in the clients instead. > In particular, the in/out socklen_t* is actually only > used for input, but there are a fair number of clients to visit: > m3-comm\tcp\src\POSIX\IP.m3 > m3-comm\tcp\src\POSIX\TCP.m3 > m3-comm\tcp\src\POSIX\TCPExtras.m3 > m3-comm\tcp\src\POSIX\TCPHack.m3 > m3-comm\tcp\src\POSIX\TCPExtras.m3 > m3-comm\tcp\src\POSIX\TCPPeer.m3 > m3-comm\udp\src\POSIX\UDPPosix.m3 > m3-demo\mentor\src\sorting\audio\MidiLineServer.m3 > m3-lectern\lecternclient\src\POSIX\LecternClientPosix.m3 > m3-libs\libm3\src\os\POSIX\SocketPosix.m3 > m3-ui\jvideo\src\POSIX\decunix\JVSink.m3 > m3-ui\jvideo\src\POSIX\decunix\Jv.m3 > From jay.krell at cornell.edu Tue Mar 17 13:50:04 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 12:50:04 +0000 Subject: [M3devel] fcntl int vs. long? Message-ID: ..hm.. C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(77):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(103):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: fcntl int vs. long? > Date: Tue, 17 Mar 2009 12:47:41 +0000 > > > Anyone want to do the research on various systems of the third parameter, for our uses, of fcntl, being int or long? > > Here is it being long on Linux: > > http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/fs/fcntl.c?v=2.6.11.8#L279 > > (unsigned long, but that's not my point -- 32 bits or 64 bits on 64 bit systems). > > The link Daniel sent has it being long on FreeBSD/AMD64. > > - Jay From jay.krell at cornell.edu Tue Mar 17 13:47:41 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 12:47:41 +0000 Subject: [M3devel] fcntl int vs. long? Message-ID: Anyone want to do the research on various systems of the third parameter, for our uses, of fcntl, being int or long? Here is it being long on Linux: http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/fs/fcntl.c?v=2.6.11.8#L279 (unsigned long, but that's not my point -- 32 bits or 64 bits on 64 bit systems). The link Daniel sent has it being long on FreeBSD/AMD64. - Jay From jay.krell at cornell.edu Wed Mar 18 10:11:44 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 18 Mar 2009 09:11:44 +0000 Subject: [M3devel] per thread data? Message-ID: I'm not looking at it right now, but doesn't seem rather piggy to have two thread locals and data on the side? I'm guessing the data on the side is needed because we need to be able to enumerate our threads, to suspend them all? I understand that having multiple thread locals optimizes their use, but it seems greedy. vs. a small heap allocation that combines them. Or in fact.. presumably there could just be one thread local that is the thread pointer, and the handler link could be put at the start, for architectures where zero offset is smaller/faster than non-zero offset. Another idea, of course, is to look into "__thread", "__declspec(thread)". On Windows and probably all platforms they exist on, they are nicely more efficient than pthread_get/setspecific, except on Windows they don't really work acceptably prior to Vista -- they only work in .exes and their static dependencies, not any .dll you load after the process starts with LoadLibrary (dlopen). Does "__thread" work well on most non-Windows platforms? i.e. even if shared object is loaded with dlopen? I could have sworn I saw code out there that was "adaptive". It easily/efficiently checked if it was loaded with LoadLibrary or not. If so, it'd TlsGet/SetValue (pthread_get/setspecific). If not, it'd use __declspec(thread) (__thread). The check was based on if __tlsindex was not zero or somesuch. I couldn't track it down though. In either case, yes, I know, one of the thread locals at least is gone on platforms that have stack walkers, e.g. Solaris, and potentially NT, and maybe others. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Mar 18 15:33:15 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 18 Mar 2009 14:33:15 +0000 Subject: [M3devel] pthreads tls initialization? Message-ID: http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html says that thread locals start as zero, but ThreadPThread.m3 does: PROCEDURE InitHandlers () = BEGIN WITH r = pthread_key_create_handlers() DO END; WITH r = pthread_setspecific_handlers(NIL) DO END; initHandlers := FALSE; END InitHandlers; Any reason for that setspecific call? I ask because I think some of this code should just be written in C. But ideally then, the Win32 code should be too. So I'm just reading them, and they differ oddly in that pthread keeps doing like: if not initialized Initialize() and Win32 allocates its thread up front locals via the Modula initializer. Maybe pthread_key is very expensive, and avoided in single threaded apps? But there aren't any, right, because the runtime creates threads, at least one for the garbage collector? - Jay From hosking at cs.purdue.edu Thu Mar 19 00:14:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Mar 2009 10:14:59 +1100 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: I have no problem putting the exception handler stack thread local into the activation thread local. On 18 Mar 2009, at 20:11, Jay wrote: > I'm not looking at it right now, but doesn't seem rather piggy to > have two thread locals and data on the side? > > > I'm guessing the data on the side is needed because we need to be > able to enumerate our threads, to suspend them all? > > > I understand that having multiple thread locals optimizes their use, > but it seems greedy. > vs. a small heap allocation that combines them. > > Or in fact.. presumably there could just be one thread local that is > the thread pointer, and the handler link could be put at the start, > for architectures where zero offset is smaller/faster than non-zero > offset. > > > Another idea, of course, is to look into "__thread", > "__declspec(thread)". > > On Windows and probably all platforms they exist on, they are nicely > more efficient than pthread_get/setspecific, except on Windows they > don't really work acceptably prior to Vista -- they only work > in .exes and their static dependencies, not any .dll you load after > the process starts with LoadLibrary (dlopen). > > > Does "__thread" work well on most non-Windows platforms? > i.e. even if shared object is loaded with dlopen? > > > I could have sworn I saw code out there that was "adaptive". > It easily/efficiently checked if it was loaded with LoadLibrary or > not. > If so, it'd TlsGet/SetValue (pthread_get/setspecific). > If not, it'd use __declspec(thread) (__thread). > The check was based on if __tlsindex was not zero or somesuch. I > couldn't track it down though. > > > In either case, yes, I know, one of the thread locals at least is > gone on platforms that have stack walkers, e.g. Solaris, and > potentially NT, and maybe others. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 19 00:22:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Mar 2009 10:22:59 +1100 Subject: [M3devel] pthreads tls initialization? In-Reply-To: References: Message-ID: The setspecific call is to initialize the handler stack to nil. It is needed. On 19 Mar 2009, at 01:33, Jay wrote: > > http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html > > > says that thread locals start as zero, but ThreadPThread.m3 does: > > > PROCEDURE InitHandlers () = > BEGIN > WITH r = pthread_key_create_handlers() DO END; > WITH r = pthread_setspecific_handlers(NIL) DO END; > initHandlers := FALSE; > END InitHandlers; > > > Any reason for that setspecific call? > > > I ask because I think some of this code should just be written in C. > But ideally then, the Win32 code should be too. > So I'm just reading them, and they differ oddly in that pthread > keeps doing like: > > > if not initialized Initialize() > > > and Win32 allocates its thread up front locals via the Modula > initializer. > Maybe pthread_key is very expensive, and avoided in single threaded > apps? > But there aren't any, right, because the runtime creates threads, at > least one for the garbage collector? > > > - Jay From jay.krell at cornell.edu Thu Mar 19 02:02:11 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 19 Mar 2009 01:02:11 +0000 Subject: [M3devel] pthreads tls initialization? In-Reply-To: References: Message-ID: But doesn't pthread_create make it so? (More so, it makes it so on any new threads.) Or it that not portable? Or did I misunderstand the opengroup web page? Or other? Or, is this because, like, the Modula-3 notion of "NIL" might not match the pthread notion of "NULL"? I don't believe in that extreme level of portability/disbelief/theory, but... Unless someone can tell me about such a system.. in which void* p = 0; printf("%p\n", p); memset(&p, 0, sizeof(p)); printf("%p\n", q); doesn't print two identical lines. I know the C standard does not guarantee this, and probably therefore Modula-3 doesn't either, but I've never heard of a system on which this isn't true. It seems more theoretical than, say, non-IEEE floating point math (which I believe exists on VAX), or, say, 16 bit integers... - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 19 Mar 2009 10:22:59 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pthreads tls initialization? > > The setspecific call is to initialize the handler stack to nil. It is > needed. > > On 19 Mar 2009, at 01:33, Jay wrote: > > > > > http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html > > > > > > says that thread locals start as zero, but ThreadPThread.m3 does: > > > > > > PROCEDURE InitHandlers () = > > BEGIN > > WITH r = pthread_key_create_handlers() DO END; > > WITH r = pthread_setspecific_handlers(NIL) DO END; > > initHandlers := FALSE; > > END InitHandlers; > > > > > > Any reason for that setspecific call? > > > > > > I ask because I think some of this code should just be written in C. > > But ideally then, the Win32 code should be too. > > So I'm just reading them, and they differ oddly in that pthread > > keeps doing like: > > > > > > if not initialized Initialize() > > > > > > and Win32 allocates its thread up front locals via the Modula > > initializer. > > Maybe pthread_key is very expensive, and avoided in single threaded > > apps? > > But there aren't any, right, because the runtime creates threads, at > > least one for the garbage collector? > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 19 02:03:57 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 19 Mar 2009 01:03:57 +0000 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: Thanks, I should get around to that "soon" then. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Thu, 19 Mar 2009 10:14:59 +1100 CC: m3devel at elegosoft.com Subject: Re: [M3devel] per thread data? I have no problem putting the exception handler stack thread local into the activation thread local. On 18 Mar 2009, at 20:11, Jay wrote: I'm not looking at it right now, but doesn't seem rather piggy to have two thread locals and data on the side? I'm guessing the data on the side is needed because we need to be able to enumerate our threads, to suspend them all? I understand that having multiple thread locals optimizes their use, but it seems greedy. vs. a small heap allocation that combines them. Or in fact.. presumably there could just be one thread local that is the thread pointer, and the handler link could be put at the start, for architectures where zero offset is smaller/faster than non-zero offset. Another idea, of course, is to look into "__thread", "__declspec(thread)". On Windows and probably all platforms they exist on, they are nicely more efficient than pthread_get/setspecific, except on Windows they don't really work acceptably prior to Vista -- they only work in .exes and their static dependencies, not any .dll you load after the process starts with LoadLibrary (dlopen). Does "__thread" work well on most non-Windows platforms? i.e. even if shared object is loaded with dlopen? I could have sworn I saw code out there that was "adaptive". It easily/efficiently checked if it was loaded with LoadLibrary or not. If so, it'd TlsGet/SetValue (pthread_get/setspecific). If not, it'd use __declspec(thread) (__thread). The check was based on if __tlsindex was not zero or somesuch. I couldn't track it down though. In either case, yes, I know, one of the thread locals at least is gone on platforms that have stack walkers, e.g. Solaris, and potentially NT, and maybe others. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 19 02:25:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Mar 2009 12:25:12 +1100 Subject: [M3devel] pthreads tls initialization? In-Reply-To: References: Message-ID: <99081981-8CEC-4392-B2F0-D47A64CA4767@cs.purdue.edu> Sorry, yes, you are correct that the value NULL will also be NIL. So, setspecific NIL is unnecessary. In any case, I do think we should just move the handler stack into Activation and pare things back to just the one threadlocal per thread. On 19 Mar 2009, at 12:02, Jay wrote: > But doesn't pthread_create make it so? (More so, it makes it so on > any new threads.) > Or it that not portable? Or did I misunderstand the opengroup web > page? Or other? > Or, is this because, like, the Modula-3 notion of "NIL" might not > match the pthread notion of "NULL"? I don't believe in that extreme > level of portability/disbelief/theory, but... > Unless someone can tell me about such a system.. in which > void* p = 0; > printf("%p\n", p); > memset(&p, 0, sizeof(p)); > printf("%p\n", q); > > doesn't print two identical lines. > > I know the C standard does not guarantee this, and probably > therefore Modula-3 doesn't either, but I've never heard of a system > on which this isn't true. > It seems more theoretical than, say, non-IEEE floating point math > (which I believe exists on VAX), or, say, 16 bit integers... > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Thu, 19 Mar 2009 10:22:59 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] pthreads tls initialization? > > > > The setspecific call is to initialize the handler stack to nil. It > is > > needed. > > > > On 19 Mar 2009, at 01:33, Jay wrote: > > > > > > > > http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html > > > > > > > > > says that thread locals start as zero, but ThreadPThread.m3 does: > > > > > > > > > PROCEDURE InitHandlers () = > > > BEGIN > > > WITH r = pthread_key_create_handlers() DO END; > > > WITH r = pthread_setspecific_handlers(NIL) DO END; > > > initHandlers := FALSE; > > > END InitHandlers; > > > > > > > > > Any reason for that setspecific call? > > > > > > > > > I ask because I think some of this code should just be written > in C. > > > But ideally then, the Win32 code should be too. > > > So I'm just reading them, and they differ oddly in that pthread > > > keeps doing like: > > > > > > > > > if not initialized Initialize() > > > > > > > > > and Win32 allocates its thread up front locals via the Modula > > > initializer. > > > Maybe pthread_key is very expensive, and avoided in single > threaded > > > apps? > > > But there aren't any, right, because the runtime creates > threads, at > > > least one for the garbage collector? > > > > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 19 08:09:09 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 19 Mar 2009 07:09:09 +0000 Subject: [M3devel] what is "activation" vs. "thread.T" In-Reply-To: <99081981-8CEC-4392-B2F0-D47A64CA4767@cs.purdue.edu> References: <99081981-8CEC-4392-B2F0-D47A64CA4767@cs.purdue.edu> Message-ID: What is meant by an "Activation" vs. a "Thread.T"? Why aren't these just one data structure? Why is there both the global "slots" and the threads are in a circularly linked list? Are there difference between "active" threads, "thread", and "slotted" threads? Or, an active thread is merely one that hasn't finished running yet, is just waiting around for someone to get its result and drop its reference to is, so it can be garbage collected? These things seem closely bound. CreateT takes an activation and sets it in the new T. CreateT always calls AssignSlot. Fork always creates one activation and one T, and always put the activation on the circular linked list. Init only calls CreateT and indirectly creates an activation via InitActivations. Therefore -- I don't see a T ever created without an activation, or vice versa. T contains act. Act does not contain T. Activation is connected back to T via an index into the global slots array. T is garbage collected. Activation is not. Activation is a thread local (pthread/win32). T is not. Is it, like, threads have to be objects, garbage collected, to fit an interface, and.. threads need to be thread local..and thread locals are hidden from the garbage collector normally??? So arbitrarily split them in two? I'm not sure I buy that. If it was true, one of them would be nearly empty, just a way to find the other. The above is mostly all/only about pthread threads. Posix threads have no "activations". Win32 threads also have an idle list. Maybe "activation" is actually small and just the untraced part, mostly, but a little extra crept in? Or, stuff more stuff in it to lighten the load on the garbage collector? Better to put untraced refs within untraced refs, than to put them within traced refs? Or maybe it is a requirement? Or maybe it has to do with locking levels and when traced vs. untraced refs can be touched? That is, the stack is deliberately in the untraced activation so..? - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 19 Mar 2009 12:25:12 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pthreads tls initialization? > > Sorry, yes, you are correct that the value NULL will also be NIL. So, setspecific NIL is unnecessary. > > In any case, I do think we should just move the handler stack into Activation and pare things back to just the one threadlocal per thread. > > On 19 Mar 2009, at 12:02, Jay wrote: > > But doesn't pthread_create make it so? (More so, it makes it so on any new threads.) > Or it that not portable? Or did I misunderstand the opengroup web page? Or other? > Or, is this because, like, the Modula-3 notion of "NIL" might not match the pthread notion of "NULL"? I don't believe in that extreme level of portability/disbelief/theory, but... > Unless someone can tell me about such a system.. in which > void* p = 0; > printf("%p\n", p); > memset(&p, 0, sizeof(p)); > printf("%p\n", q); > > doesn't print two identical lines. > > I know the C standard does not guarantee this, and probably therefore Modula-3 doesn't either, but I've never heard of a system on which this isn't true. > It seems more theoretical than, say, non-IEEE floating point math (which I believe exists on VAX), or, say, 16 bit integers... > > - Jay > > >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Thu, 19 Mar 2009 10:22:59 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pthreads tls initialization? >> >> The setspecific call is to initialize the handler stack to nil. It is >> needed. >> >> On 19 Mar 2009, at 01:33, Jay wrote: >> >>> >>> http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html >>> >>> >>> says that thread locals start as zero, but ThreadPThread.m3 does: >>> >>> >>> PROCEDURE InitHandlers () = >>> BEGIN >>> WITH r = pthread_key_create_handlers() DO END; >>> WITH r = pthread_setspecific_handlers(NIL) DO END; >>> initHandlers := FALSE; >>> END InitHandlers; >>> >>> >>> Any reason for that setspecific call? >>> >>> >>> I ask because I think some of this code should just be written in C. >>> But ideally then, the Win32 code should be too. >>> So I'm just reading them, and they differ oddly in that pthread >>> keeps doing like: >>> >>> >>> if not initialized Initialize() >>> >>> >>> and Win32 allocates its thread up front locals via the Modula >>> initializer. >>> Maybe pthread_key is very expensive, and avoided in single threaded >>> apps? >>> But there aren't any, right, because the runtime creates threads, at >>> least one for the garbage collector? >>> >>> >>> - Jay >> > From jay.krell at cornell.edu Thu Mar 19 08:47:47 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 19 Mar 2009 07:47:47 +0000 Subject: [M3devel] formsedit crash during startup sometimes? Message-ID: Formsedit on SOLgnu also crashes, sometimes, during startup. It doesn't seem to crash in a debugger, but you can load up the core dump after a crash. It looks very similar as on PPC_DARWIN. In both cases, it is dereferencing the value 4, just after calling RTHooks__CheckLoadTracedRef? Relevant? Coincidence? -bash-3.00$ uname -a SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100 -bash-3.00$ rm core -bash-3.00$ ./formsedit Segmentation Fault (core dumped) -bash-3.00$ dbx ./formsedit ./core ... t at 2 (l at 2) terminated by signal KILL (Killed) 0xfe3c03d0: ___nanosleep+0x0008: bcc,a,pt %icc,___nanosleep+0x18 ! 0xfe3c03e0 (dbx) lwps l at 1 LWP suspended in lwp_yield() >l at 2 LWP suspended in ___nanosleep() l at 3 LWP suspended in __lwp_park() l at 4 LWP suspended in ___nanosleep() l at 11 LWP suspended in __lwp_park() l at 12 LWP suspended in __lwp_park() l at 13 LWP suspended in __lwp_park() o l at 27 signal SIGSEGV in ScrollerVBTClass__PaintViewWithShadows() l at 28 LWP suspended in __lwp_park() (dbx) lwp l at 27 t at 27 (l at 27) stopped in ScrollerVBTClass__PaintViewWithShadows at 0xff1b945c 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld [%g1], %g1 (dbx) dis $pc - 0x10 dbx: warning: unknown language, 'c' assumed 0xff1b941c: ScrollerVBTClass__PaintViewWithShadows+0x0300: inc -4, %g1 0xff1b9420: ScrollerVBTClass__PaintViewWithShadows+0x0304: ld [%g1], %g1 0xff1b9424: ScrollerVBTClass__PaintViewWithShadows+0x0308: sll %g1, 22, %g1 0xff1b9428: ScrollerVBTClass__PaintViewWithShadows+0x030c: srl %g1, 31, %g1 0xff1b942c: ScrollerVBTClass__PaintViewWithShadows+0x0310: btog 1, %g1 0xff1b9430: ScrollerVBTClass__PaintViewWithShadows+0x0314: and %g1, 255, %g1 0xff1b9434: ScrollerVBTClass__PaintViewWithShadows+0x0318: cmp %g1, 0 0xff1b9438: ScrollerVBTClass__PaintViewWithShadows+0x031c: bne,pt %icc,ScrollerVBTClass__Pain tViewWithShadows+0x334 ! 0xff1b9450 0xff1b943c: ScrollerVBTClass__PaintViewWithShadows+0x0320: nop 0xff1b9440: ScrollerVBTClass__PaintViewWithShadows+0x0324: ld [%fp - 24], %g1 (dbx) dis 0xff1b9444: ScrollerVBTClass__PaintViewWithShadows+0x0328: mov %g1, %o0 0xff1b9448: ScrollerVBTClass__PaintViewWithShadows+0x032c: call RTHooks__CheckLoadTracedRef [PLT] ! 0xff2a9518 0xff1b944c: ScrollerVBTClass__PaintViewWithShadows+0x0330: nop 0xff1b9450: ScrollerVBTClass__PaintViewWithShadows+0x0334: ld [%fp + 68], %g3 0xff1b9454: ScrollerVBTClass__PaintViewWithShadows+0x0338: ld [%fp - 24], %g1 0xff1b9458: ScrollerVBTClass__PaintViewWithShadows+0x033c: inc 4, %g1 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld [%g1], %g1 0xff1b9460: ScrollerVBTClass__PaintViewWithShadows+0x0344: st %g1, [%fp - 180] 0xff1b9464: ScrollerVBTClass__PaintViewWithShadows+0x0348: add %fp, -40, %g1 0xff1b9468: ScrollerVBTClass__PaintViewWithShadows+0x034c: add %fp, -180, %g2 (dbx) print $g1 $g1 = 4ULL (dbx) I believe it is on the last line of the function, the PaintTint call (due to what PPC_DARWIN showed). PROCEDURE PaintViewWithShadows (v: T) = VAR dom : Rect.T; stripe: Rect.T; r : Rect.T; f : Rect.Partition; BEGIN dom := VBT.Domain(v); stripe := ComputeStripe(v, dom); (* Paint the scroll. We are careful not to draw the area of the trough that will be covered by the stripe. This helps reduce the flicker. *) r := Rect.Inset(dom, v.shadowPixels); ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Lowered, r, dom); Rect.Factor(r, stripe, f, 0, 0); FOR i := FIRST(f) TO LAST(f) DO IF i # 2 AND NOT Rect.IsEmpty(f[i]) THEN VBT.PaintTint(v, f[i], v.troughColor); END; END; (* Paint the stripe. *) r := Rect.Inset(stripe, v.shadowPixels); ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, r, stripe); VBT.PaintTint(v, r, v.shadow.bg); END PaintViewWithShadows; I'm somewhat just showing people how to get started debugging it, in case folks are as afraid of command line debuggers as I used to be. - Jay From jay.krell at cornell.edu Thu Mar 19 11:22:08 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 19 Mar 2009 10:22:08 +0000 Subject: [M3devel] formsedit crash during startup sometimes? In-Reply-To: References: Message-ID: RTHooks__CheckLoadTracedRef is I'm sure innocent. It gets called before any pointer deref, I guess. The problem is the pointer is sometimes null, sometimes not. And why that is is what we need to figure out. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Thu, 19 Mar 2009 07:47:47 +0000 > Subject: [M3devel] formsedit crash during startup sometimes? > > > Formsedit on SOLgnu also crashes, sometimes, during startup. > It doesn't seem to crash in a debugger, but you can load up the core dump after a crash. It looks very similar as on PPC_DARWIN. > > > In both cases, it is dereferencing the value 4, just after calling RTHooks__CheckLoadTracedRef? Relevant? Coincidence? > > > -bash-3.00$ uname -a > SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100 > -bash-3.00$ rm core > -bash-3.00$ ./formsedit > Segmentation Fault (core dumped) > -bash-3.00$ dbx ./formsedit ./core > ... > t at 2 (l at 2) terminated by signal KILL (Killed) > 0xfe3c03d0: ___nanosleep+0x0008: bcc,a,pt %icc,___nanosleep+0x18 ! 0xfe3c03e0 > (dbx) lwps > l at 1 LWP suspended in lwp_yield() > >l at 2 LWP suspended in ___nanosleep() > l at 3 LWP suspended in __lwp_park() > l at 4 LWP suspended in ___nanosleep() > l at 11 LWP suspended in __lwp_park() > l at 12 LWP suspended in __lwp_park() > l at 13 LWP suspended in __lwp_park() > o l at 27 signal SIGSEGV in ScrollerVBTClass__PaintViewWithShadows() > l at 28 LWP suspended in __lwp_park() > (dbx) lwp l at 27 > t at 27 (l at 27) stopped in ScrollerVBTClass__PaintViewWithShadows at 0xff1b945c > 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld [%g1], %g1 > (dbx) dis $pc - 0x10 > dbx: warning: unknown language, 'c' assumed > 0xff1b941c: ScrollerVBTClass__PaintViewWithShadows+0x0300: inc -4, %g1 > 0xff1b9420: ScrollerVBTClass__PaintViewWithShadows+0x0304: ld [%g1], %g1 > 0xff1b9424: ScrollerVBTClass__PaintViewWithShadows+0x0308: sll %g1, 22, %g1 > 0xff1b9428: ScrollerVBTClass__PaintViewWithShadows+0x030c: srl %g1, 31, %g1 > 0xff1b942c: ScrollerVBTClass__PaintViewWithShadows+0x0310: btog 1, %g1 > 0xff1b9430: ScrollerVBTClass__PaintViewWithShadows+0x0314: and %g1, 255, %g1 > 0xff1b9434: ScrollerVBTClass__PaintViewWithShadows+0x0318: cmp %g1, 0 > 0xff1b9438: ScrollerVBTClass__PaintViewWithShadows+0x031c: bne,pt %icc,ScrollerVBTClass__Pain > tViewWithShadows+0x334 ! 0xff1b9450 > 0xff1b943c: ScrollerVBTClass__PaintViewWithShadows+0x0320: nop > 0xff1b9440: ScrollerVBTClass__PaintViewWithShadows+0x0324: ld [%fp - 24], %g1 > (dbx) dis > 0xff1b9444: ScrollerVBTClass__PaintViewWithShadows+0x0328: mov %g1, %o0 > 0xff1b9448: ScrollerVBTClass__PaintViewWithShadows+0x032c: call RTHooks__CheckLoadTracedRef > [PLT] ! 0xff2a9518 > 0xff1b944c: ScrollerVBTClass__PaintViewWithShadows+0x0330: nop > 0xff1b9450: ScrollerVBTClass__PaintViewWithShadows+0x0334: ld [%fp + 68], %g3 > 0xff1b9454: ScrollerVBTClass__PaintViewWithShadows+0x0338: ld [%fp - 24], %g1 > 0xff1b9458: ScrollerVBTClass__PaintViewWithShadows+0x033c: inc 4, %g1 > 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld [%g1], %g1 > 0xff1b9460: ScrollerVBTClass__PaintViewWithShadows+0x0344: st %g1, [%fp - 180] > 0xff1b9464: ScrollerVBTClass__PaintViewWithShadows+0x0348: add %fp, -40, %g1 > 0xff1b9468: ScrollerVBTClass__PaintViewWithShadows+0x034c: add %fp, -180, %g2 > (dbx) print $g1 > $g1 = 4ULL > (dbx) > > I believe it is on the last line of the function, the PaintTint call (due to what PPC_DARWIN showed). > > > PROCEDURE PaintViewWithShadows (v: T) = > VAR > dom : Rect.T; > stripe: Rect.T; > r : Rect.T; > f : Rect.Partition; > BEGIN > dom := VBT.Domain(v); > stripe := ComputeStripe(v, dom); > (* Paint the scroll. We are careful not to draw the area of the > trough that will be covered by the stripe. This helps reduce > the flicker. *) > r := Rect.Inset(dom, v.shadowPixels); > ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Lowered, > r, dom); > Rect.Factor(r, stripe, f, 0, 0); > FOR i := FIRST(f) TO LAST(f) DO > IF i # 2 AND NOT Rect.IsEmpty(f[i]) THEN > VBT.PaintTint(v, f[i], v.troughColor); > END; > END; > (* Paint the stripe. *) > r := Rect.Inset(stripe, v.shadowPixels); > ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, > r, stripe); > VBT.PaintTint(v, r, v.shadow.bg); > END PaintViewWithShadows; > > > I'm somewhat just showing people how to get started debugging it, in case folks are as afraid of command line debuggers as I used to be. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 19 12:07:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Mar 2009 22:07:56 +1100 Subject: [M3devel] formsedit crash during startup sometimes? In-Reply-To: References: Message-ID: This is a new bug. What changes introduced it? On 19 Mar 2009, at 21:22, Jay wrote: > RTHooks__CheckLoadTracedRef is I'm sure innocent. It gets called > before any pointer deref, I guess. The problem is the pointer is > sometimes null, sometimes not. And why that is is what we need to > figure out. > > - Jay > > > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Thu, 19 Mar 2009 07:47:47 +0000 > > Subject: [M3devel] formsedit crash during startup sometimes? > > > > > > Formsedit on SOLgnu also crashes, sometimes, during startup. > > It doesn't seem to crash in a debugger, but you can load up the > core dump after a crash. It looks very similar as on PPC_DARWIN. > > > > > > In both cases, it is dereferencing the value 4, just after calling > RTHooks__CheckLoadTracedRef? Relevant? Coincidence? > > > > > > -bash-3.00$ uname -a > > SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100 > > -bash-3.00$ rm core > > -bash-3.00$ ./formsedit > > Segmentation Fault (core dumped) > > -bash-3.00$ dbx ./formsedit ./core > > ... > > t at 2 (l at 2) terminated by signal KILL (Killed) > > 0xfe3c03d0: ___nanosleep+0x0008: bcc,a,pt %icc,___nanosleep+0x18 ! > 0xfe3c03e0 > > (dbx) lwps > > l at 1 LWP suspended in lwp_yield() > > >l at 2 LWP suspended in ___nanosleep() > > l at 3 LWP suspended in __lwp_park() > > l at 4 LWP suspended in ___nanosleep() > > l at 11 LWP suspended in __lwp_park() > > l at 12 LWP suspended in __lwp_park() > > l at 13 LWP suspended in __lwp_park() > > o l at 27 signal SIGSEGV in ScrollerVBTClass__PaintViewWithShadows() > > l at 28 LWP suspended in __lwp_park() > > (dbx) lwp l at 27 > > t at 27 (l at 27) stopped in ScrollerVBTClass__PaintViewWithShadows at > 0xff1b945c > > 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld > [%g1], %g1 > > (dbx) dis $pc - 0x10 > > dbx: warning: unknown language, 'c' assumed > > 0xff1b941c: ScrollerVBTClass__PaintViewWithShadows+0x0300: inc -4, > %g1 > > 0xff1b9420: ScrollerVBTClass__PaintViewWithShadows+0x0304: ld > [%g1], %g1 > > 0xff1b9424: ScrollerVBTClass__PaintViewWithShadows+0x0308: sll > %g1, 22, %g1 > > 0xff1b9428: ScrollerVBTClass__PaintViewWithShadows+0x030c: srl > %g1, 31, %g1 > > 0xff1b942c: ScrollerVBTClass__PaintViewWithShadows+0x0310: btog 1, > %g1 > > 0xff1b9430: ScrollerVBTClass__PaintViewWithShadows+0x0314: and > %g1, 255, %g1 > > 0xff1b9434: ScrollerVBTClass__PaintViewWithShadows+0x0318: cmp > %g1, 0 > > 0xff1b9438: ScrollerVBTClass__PaintViewWithShadows+0x031c: bne,pt > %icc,ScrollerVBTClass__Pain > > tViewWithShadows+0x334 ! 0xff1b9450 > > 0xff1b943c: ScrollerVBTClass__PaintViewWithShadows+0x0320: nop > > 0xff1b9440: ScrollerVBTClass__PaintViewWithShadows+0x0324: ld [%fp > - 24], %g1 > > (dbx) dis > > 0xff1b9444: ScrollerVBTClass__PaintViewWithShadows+0x0328: mov > %g1, %o0 > > 0xff1b9448: ScrollerVBTClass__PaintViewWithShadows+0x032c: call > RTHooks__CheckLoadTracedRef > > [PLT] ! 0xff2a9518 > > 0xff1b944c: ScrollerVBTClass__PaintViewWithShadows+0x0330: nop > > 0xff1b9450: ScrollerVBTClass__PaintViewWithShadows+0x0334: ld [%fp > + 68], %g3 > > 0xff1b9454: ScrollerVBTClass__PaintViewWithShadows+0x0338: ld [%fp > - 24], %g1 > > 0xff1b9458: ScrollerVBTClass__PaintViewWithShadows+0x033c: inc 4, > %g1 > > 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld > [%g1], %g1 > > 0xff1b9460: ScrollerVBTClass__PaintViewWithShadows+0x0344: st %g1, > [%fp - 180] > > 0xff1b9464: ScrollerVBTClass__PaintViewWithShadows+0x0348: add > %fp, -40, %g1 > > 0xff1b9468: ScrollerVBTClass__PaintViewWithShadows+0x034c: add > %fp, -180, %g2 > > (dbx) print $g1 > > $g1 = 4ULL > > (dbx) > > > > I believe it is on the last line of the function, the PaintTint > call (due to what PPC_DARWIN showed). > > > > > > PROCEDURE PaintViewWithShadows (v: T) = > > VAR > > dom : Rect.T; > > stripe: Rect.T; > > r : Rect.T; > > f : Rect.Partition; > > BEGIN > > dom := VBT.Domain(v); > > stripe := ComputeStripe(v, dom); > > (* Paint the scroll. We are careful not to draw the area of the > > trough that will be covered by the stripe. This helps reduce > > the flicker. *) > > r := Rect.Inset(dom, v.shadowPixels); > > ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Lowered, > > r, dom); > > Rect.Factor(r, stripe, f, 0, 0); > > FOR i := FIRST(f) TO LAST(f) DO > > IF i # 2 AND NOT Rect.IsEmpty(f[i]) THEN > > VBT.PaintTint(v, f[i], v.troughColor); > > END; > > END; > > (* Paint the stripe. *) > > r := Rect.Inset(stripe, v.shadowPixels); > > ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, > > r, stripe); > > VBT.PaintTint(v, r, v.shadow.bg); > > END PaintViewWithShadows; > > > > > > I'm somewhat just showing people how to get started debugging it, > in case folks are as afraid of command line debuggers as I used to be. > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Thu Mar 19 13:27:11 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 19 Mar 2009 07:27:11 -0500 Subject: [M3devel] [Fwd: Prentice-Hall says no] Message-ID: <49C23A1F.1070800@bellsouth.net> An embedded message was scrubbed... From: Greg Nelson Subject: Prentice-Hall says no Date: Wed, 18 Mar 2009 21:17:19 -0700 Size: 4747 URL: From hosking at cs.purdue.edu Thu Mar 19 12:05:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Mar 2009 22:05:02 +1100 Subject: [M3devel] what is "activation" vs. "thread.T" In-Reply-To: References: <99081981-8CEC-4392-B2F0-D47A64CA4767@cs.purdue.edu> Message-ID: On 19 Mar 2009, at 18:09, Jay wrote: > > What is meant by an "Activation" UNTRACED > vs. a "Thread.T"? TRACED I don't recall the specifics, but it was needed at some point. Here be dragons. I'll try to reconstruct the reasoning... > Why aren't these just one data structure? > > > Why is there both the global "slots" and the threads are in a > circularly linked list? > > Are there difference between "active" threads, "thread", and > "slotted" threads? > Or, an active thread is merely one that hasn't finished running yet, > is just waiting around for someone to get its result and drop its > reference to is, so it can be garbage collected? > > These things seem closely bound. > CreateT takes an activation and sets it in the new T. > CreateT always calls AssignSlot. > > Fork always creates one activation and one T, and always put the > activation on the circular linked list. > > Init only calls CreateT and indirectly creates an activation via > InitActivations. > > Therefore -- I don't see a T ever created without an activation, or > vice versa. > > T contains act. > Act does not contain T. > Activation is connected back to T via an index into the global slots > array. > > T is garbage collected. > Activation is not. > Activation is a thread local (pthread/win32). > T is not. > > Is it, like, threads have to be objects, garbage collected, to fit > an interface, and.. threads need to be thread local..and thread > locals are hidden from the garbage collector normally??? So > arbitrarily split them in two? > I'm not sure I buy that. If it was true, one of them would be nearly > empty, just a way to find the other. > > > The above is mostly all/only about pthread threads. > Posix threads have no "activations". > Win32 threads also have an idle list. > > Maybe "activation" is actually small and just the untraced part, > mostly, but a little extra crept in? Or, stuff more stuff in it to > lighten the load on the garbage collector? Better to put untraced > refs within untraced refs, than to put them within traced refs? Or > maybe it is a requirement? > > Or maybe it has to do with locking levels and when traced vs. > untraced refs can be touched? That is, the stack is deliberately in > the untraced activation so..? > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Thu, 19 Mar 2009 12:25:12 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pthreads tls initialization? >> >> Sorry, yes, you are correct that the value NULL will also be NIL. >> So, setspecific NIL is unnecessary. >> >> In any case, I do think we should just move the handler stack into >> Activation and pare things back to just the one threadlocal per >> thread. >> >> On 19 Mar 2009, at 12:02, Jay wrote: >> >> But doesn't pthread_create make it so? (More so, it makes it so on >> any new threads.) >> Or it that not portable? Or did I misunderstand the opengroup web >> page? Or other? >> Or, is this because, like, the Modula-3 notion of "NIL" might not >> match the pthread notion of "NULL"? I don't believe in that extreme >> level of portability/disbelief/theory, but... >> Unless someone can tell me about such a system.. in which >> void* p = 0; >> printf("%p\n", p); >> memset(&p, 0, sizeof(p)); >> printf("%p\n", q); >> >> doesn't print two identical lines. >> >> I know the C standard does not guarantee this, and probably >> therefore Modula-3 doesn't either, but I've never heard of a system >> on which this isn't true. >> It seems more theoretical than, say, non-IEEE floating point math >> (which I believe exists on VAX), or, say, 16 bit integers... >> >> - Jay >> >> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Thu, 19 Mar 2009 10:22:59 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] pthreads tls initialization? >>> >>> The setspecific call is to initialize the handler stack to nil. It >>> is >>> needed. >>> >>> On 19 Mar 2009, at 01:33, Jay wrote: >>> >>>> >>>> http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html >>>> >>>> >>>> says that thread locals start as zero, but ThreadPThread.m3 does: >>>> >>>> >>>> PROCEDURE InitHandlers () = >>>> BEGIN >>>> WITH r = pthread_key_create_handlers() DO END; >>>> WITH r = pthread_setspecific_handlers(NIL) DO END; >>>> initHandlers := FALSE; >>>> END InitHandlers; >>>> >>>> >>>> Any reason for that setspecific call? >>>> >>>> >>>> I ask because I think some of this code should just be written in >>>> C. >>>> But ideally then, the Win32 code should be too. >>>> So I'm just reading them, and they differ oddly in that pthread >>>> keeps doing like: >>>> >>>> >>>> if not initialized Initialize() >>>> >>>> >>>> and Win32 allocates its thread up front locals via the Modula >>>> initializer. >>>> Maybe pthread_key is very expensive, and avoided in single threaded >>>> apps? >>>> But there aren't any, right, because the runtime creates threads, >>>> at >>>> least one for the garbage collector? >>>> >>>> >>>> - Jay >>> >> From jay.krell at cornell.edu Fri Mar 20 00:18:17 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 19 Mar 2009 23:18:17 +0000 Subject: [M3devel] formsedit crash during startup sometimes? In-Reply-To: References: Message-ID: I don't know yet. I just know that it happens before and after switching to "new small unix/*.i3 files", so not that. I'm away for a few days with only an x86 laptop, I might get around to testing something in a virtual machine, see if repros. Otherwise it'll wait a bit. Soon I will probably resort to going back to 5.4.0 or something, verifying no repro, then do "time bisection" or whatever you call it ("binary search"?) -- jump ahead some chunk of time, ideally half way between then and now, see if it repros, jump forward or backward half again depending on if it repros, etc.. Wouldn't it be super cool, though if I could just issue one command, wait overnight or whatever, and voila, several of those builds done, in both directions, just awaiting human test/observation? Yeah.. I don't even know how yet to sync an entire CVS tree to a date yet, maybe cvs upd -d? (Nice thing about 5.4.0 is I don't need CVS to identify it.) I also need to ensure that the non-repro case hits the line in question and if so..well, what I'd really love to do, but not sure how viable it is, is write code within the running system (before it runs), to set a hardware breakpoint on the appropriate address, for each appropriate address as the data types are created, and just have dump core when it hits. I wasn't able to get it to even repro in debugger for SOLgnu. I'll try PPC_DARWIN in a debugger, but even if it repros I'm a bit pessimistic on tracking it down. Bisection while tedious and slow should definitely converge on the answer. - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] formsedit crash during startup sometimes? > Date: Thu, 19 Mar 2009 22:07:56 +1100 > > This is a new bug. What changes introduced it? > > On 19 Mar 2009, at 21:22, Jay wrote: > > RTHooks__CheckLoadTracedRef is I'm sure innocent. It gets called before any pointer deref, I guess. The problem is the pointer is sometimes null, sometimes not. And why that is is what we need to figure out. > > - Jay > > >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Thu, 19 Mar 2009 07:47:47 +0000 >> Subject: [M3devel] formsedit crash during startup sometimes? >> >> >> Formsedit on SOLgnu also crashes, sometimes, during startup. >> It doesn't seem to crash in a debugger, but you can load up the core dump after a crash. It looks very similar as on PPC_DARWIN. >> >> >> In both cases, it is dereferencing the value 4, just after calling RTHooks__CheckLoadTracedRef? Relevant? Coincidence? >> >> >> -bash-3.00$ uname -a >> SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100 >> -bash-3.00$ rm core >> -bash-3.00$ ./formsedit >> Segmentation Fault (core dumped) >> -bash-3.00$ dbx ./formsedit ./core >> ... >> t at 2 (l at 2) terminated by signal KILL (Killed) >> 0xfe3c03d0: ___nanosleep+0x0008: bcc,a,pt %icc,___nanosleep+0x18 ! 0xfe3c03e0 >> (dbx) lwps >> l at 1 LWP suspended in lwp_yield() >>>l at 2 LWP suspended in ___nanosleep() >> l at 3 LWP suspended in __lwp_park() >> l at 4 LWP suspended in ___nanosleep() >> l at 11 LWP suspended in __lwp_park() >> l at 12 LWP suspended in __lwp_park() >> l at 13 LWP suspended in __lwp_park() >> o l at 27 signal SIGSEGV in ScrollerVBTClass__PaintViewWithShadows() >> l at 28 LWP suspended in __lwp_park() >> (dbx) lwp l at 27 >> t at 27 (l at 27) stopped in ScrollerVBTClass__PaintViewWithShadows at 0xff1b945c >> 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld [%g1], %g1 >> (dbx) dis $pc - 0x10 >> dbx: warning: unknown language, 'c' assumed >> 0xff1b941c: ScrollerVBTClass__PaintViewWithShadows+0x0300: inc -4, %g1 >> 0xff1b9420: ScrollerVBTClass__PaintViewWithShadows+0x0304: ld [%g1], %g1 >> 0xff1b9424: ScrollerVBTClass__PaintViewWithShadows+0x0308: sll %g1, 22, %g1 >> 0xff1b9428: ScrollerVBTClass__PaintViewWithShadows+0x030c: srl %g1, 31, %g1 >> 0xff1b942c: ScrollerVBTClass__PaintViewWithShadows+0x0310: btog 1, %g1 >> 0xff1b9430: ScrollerVBTClass__PaintViewWithShadows+0x0314: and %g1, 255, %g1 >> 0xff1b9434: ScrollerVBTClass__PaintViewWithShadows+0x0318: cmp %g1, 0 >> 0xff1b9438: ScrollerVBTClass__PaintViewWithShadows+0x031c: bne,pt %icc,ScrollerVBTClass__Pain >> tViewWithShadows+0x334 ! 0xff1b9450 >> 0xff1b943c: ScrollerVBTClass__PaintViewWithShadows+0x0320: nop >> 0xff1b9440: ScrollerVBTClass__PaintViewWithShadows+0x0324: ld [%fp - 24], %g1 >> (dbx) dis >> 0xff1b9444: ScrollerVBTClass__PaintViewWithShadows+0x0328: mov %g1, %o0 >> 0xff1b9448: ScrollerVBTClass__PaintViewWithShadows+0x032c: call RTHooks__CheckLoadTracedRef >> [PLT] ! 0xff2a9518 >> 0xff1b944c: ScrollerVBTClass__PaintViewWithShadows+0x0330: nop >> 0xff1b9450: ScrollerVBTClass__PaintViewWithShadows+0x0334: ld [%fp + 68], %g3 >> 0xff1b9454: ScrollerVBTClass__PaintViewWithShadows+0x0338: ld [%fp - 24], %g1 >> 0xff1b9458: ScrollerVBTClass__PaintViewWithShadows+0x033c: inc 4, %g1 >> 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld [%g1], %g1 >> 0xff1b9460: ScrollerVBTClass__PaintViewWithShadows+0x0344: st %g1, [%fp - 180] >> 0xff1b9464: ScrollerVBTClass__PaintViewWithShadows+0x0348: add %fp, -40, %g1 >> 0xff1b9468: ScrollerVBTClass__PaintViewWithShadows+0x034c: add %fp, -180, %g2 >> (dbx) print $g1 >> $g1 = 4ULL >> (dbx) >> >> I believe it is on the last line of the function, the PaintTint call (due to what PPC_DARWIN showed). >> >> >> PROCEDURE PaintViewWithShadows (v: T) = >> VAR >> dom : Rect.T; >> stripe: Rect.T; >> r : Rect.T; >> f : Rect.Partition; >> BEGIN >> dom := VBT.Domain(v); >> stripe := ComputeStripe(v, dom); >> (* Paint the scroll. We are careful not to draw the area of the >> trough that will be covered by the stripe. This helps reduce >> the flicker. *) >> r := Rect.Inset(dom, v.shadowPixels); >> ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Lowered, >> r, dom); >> Rect.Factor(r, stripe, f, 0, 0); >> FOR i := FIRST(f) TO LAST(f) DO >> IF i # 2 AND NOT Rect.IsEmpty(f[i]) THEN >> VBT.PaintTint(v, f[i], v.troughColor); >> END; >> END; >> (* Paint the stripe. *) >> r := Rect.Inset(stripe, v.shadowPixels); >> ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, >> r, stripe); >> VBT.PaintTint(v, r, v.shadow.bg); >> END PaintViewWithShadows; >> >> >> I'm somewhat just showing people how to get started debugging it, in case folks are as afraid of command line debuggers as I used to be. >> >> >> - Jay > From hosking at cs.purdue.edu Fri Mar 20 00:39:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 20 Mar 2009 10:39:44 +1100 Subject: [M3devel] formsedit crash during startup sometimes? In-Reply-To: References: Message-ID: I may have some time to look at this later next week. On 20 Mar 2009, at 10:18, Jay wrote: > > I don't know yet. > I just know that it happens before and after switching to "new small > unix/*.i3 files", so not that. > > > I'm away for a few days with only an x86 laptop, I might get around > to testing something in a virtual machine, see if repros. Otherwise > it'll wait a bit. > > > Soon I will probably resort to going back to 5.4.0 or something, > verifying no repro, then do "time bisection" or whatever you call it > ("binary search"?) -- jump ahead some chunk of time, ideally half > way between then and now, see if it repros, jump forward or backward > half again depending on if it repros, etc.. > > > Wouldn't it be super cool, though if I could just issue one command, > wait overnight or whatever, and voila, several of those builds done, > in both directions, just awaiting human test/observation? Yeah.. > > > I don't even know how yet to sync an entire CVS tree to a date yet, > maybe cvs upd -d? > (Nice thing about 5.4.0 is I don't need CVS to identify it.) > > > I also need to ensure that the non-repro case hits the line in > question and if so..well, what I'd really love to do, but not sure > how viable it is, is write code within the running system (before it > runs), to set a hardware breakpoint on the appropriate address, for > each appropriate address as the data types are created, and just > have dump core when it hits. I wasn't able to get it to even repro > in debugger for SOLgnu. I'll try PPC_DARWIN in a debugger, but even > if it repros I'm a bit pessimistic on tracking it down. > > Bisection while tedious and slow should definitely converge on the > answer. > > > - Jay > > > ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] formsedit crash during startup sometimes? >> Date: Thu, 19 Mar 2009 22:07:56 +1100 >> >> This is a new bug. What changes introduced it? >> >> On 19 Mar 2009, at 21:22, Jay wrote: >> >> RTHooks__CheckLoadTracedRef is I'm sure innocent. It gets called >> before any pointer deref, I guess. The problem is the pointer is >> sometimes null, sometimes not. And why that is is what we need to >> figure out. >> >> - Jay >> >> >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Thu, 19 Mar 2009 07:47:47 +0000 >>> Subject: [M3devel] formsedit crash during startup sometimes? >>> >>> >>> Formsedit on SOLgnu also crashes, sometimes, during startup. >>> It doesn't seem to crash in a debugger, but you can load up the >>> core dump after a crash. It looks very similar as on PPC_DARWIN. >>> >>> >>> In both cases, it is dereferencing the value 4, just after calling >>> RTHooks__CheckLoadTracedRef? Relevant? Coincidence? >>> >>> >>> -bash-3.00$ uname -a >>> SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100 >>> -bash-3.00$ rm core >>> -bash-3.00$ ./formsedit >>> Segmentation Fault (core dumped) >>> -bash-3.00$ dbx ./formsedit ./core >>> ... >>> t at 2 (l at 2) terminated by signal KILL (Killed) >>> 0xfe3c03d0: ___nanosleep+0x0008: bcc,a,pt %icc,___nanosleep+0x18 ! >>> 0xfe3c03e0 >>> (dbx) lwps >>> l at 1 LWP suspended in lwp_yield() >>>> l at 2 LWP suspended in ___nanosleep() >>> l at 3 LWP suspended in __lwp_park() >>> l at 4 LWP suspended in ___nanosleep() >>> l at 11 LWP suspended in __lwp_park() >>> l at 12 LWP suspended in __lwp_park() >>> l at 13 LWP suspended in __lwp_park() >>> o l at 27 signal SIGSEGV in ScrollerVBTClass__PaintViewWithShadows() >>> l at 28 LWP suspended in __lwp_park() >>> (dbx) lwp l at 27 >>> t at 27 (l at 27) stopped in ScrollerVBTClass__PaintViewWithShadows at >>> 0xff1b945c >>> 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld >>> [%g1], %g1 >>> (dbx) dis $pc - 0x10 >>> dbx: warning: unknown language, 'c' assumed >>> 0xff1b941c: ScrollerVBTClass__PaintViewWithShadows+0x0300: inc -4, >>> %g1 >>> 0xff1b9420: ScrollerVBTClass__PaintViewWithShadows+0x0304: ld >>> [%g1], %g1 >>> 0xff1b9424: ScrollerVBTClass__PaintViewWithShadows+0x0308: sll >>> %g1, 22, %g1 >>> 0xff1b9428: ScrollerVBTClass__PaintViewWithShadows+0x030c: srl >>> %g1, 31, %g1 >>> 0xff1b942c: ScrollerVBTClass__PaintViewWithShadows+0x0310: btog 1, >>> %g1 >>> 0xff1b9430: ScrollerVBTClass__PaintViewWithShadows+0x0314: and >>> %g1, 255, %g1 >>> 0xff1b9434: ScrollerVBTClass__PaintViewWithShadows+0x0318: cmp >>> %g1, 0 >>> 0xff1b9438: ScrollerVBTClass__PaintViewWithShadows+0x031c: bne,pt >>> %icc,ScrollerVBTClass__Pain >>> tViewWithShadows+0x334 ! 0xff1b9450 >>> 0xff1b943c: ScrollerVBTClass__PaintViewWithShadows+0x0320: nop >>> 0xff1b9440: ScrollerVBTClass__PaintViewWithShadows+0x0324: ld [%fp >>> - 24], %g1 >>> (dbx) dis >>> 0xff1b9444: ScrollerVBTClass__PaintViewWithShadows+0x0328: mov >>> %g1, %o0 >>> 0xff1b9448: ScrollerVBTClass__PaintViewWithShadows+0x032c: call >>> RTHooks__CheckLoadTracedRef >>> [PLT] ! 0xff2a9518 >>> 0xff1b944c: ScrollerVBTClass__PaintViewWithShadows+0x0330: nop >>> 0xff1b9450: ScrollerVBTClass__PaintViewWithShadows+0x0334: ld [%fp >>> + 68], %g3 >>> 0xff1b9454: ScrollerVBTClass__PaintViewWithShadows+0x0338: ld [%fp >>> - 24], %g1 >>> 0xff1b9458: ScrollerVBTClass__PaintViewWithShadows+0x033c: inc 4, >>> %g1 >>> 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld >>> [%g1], %g1 >>> 0xff1b9460: ScrollerVBTClass__PaintViewWithShadows+0x0344: st %g1, >>> [%fp - 180] >>> 0xff1b9464: ScrollerVBTClass__PaintViewWithShadows+0x0348: add >>> %fp, -40, %g1 >>> 0xff1b9468: ScrollerVBTClass__PaintViewWithShadows+0x034c: add >>> %fp, -180, %g2 >>> (dbx) print $g1 >>> $g1 = 4ULL >>> (dbx) >>> >>> I believe it is on the last line of the function, the PaintTint >>> call (due to what PPC_DARWIN showed). >>> >>> >>> PROCEDURE PaintViewWithShadows (v: T) = >>> VAR >>> dom : Rect.T; >>> stripe: Rect.T; >>> r : Rect.T; >>> f : Rect.Partition; >>> BEGIN >>> dom := VBT.Domain(v); >>> stripe := ComputeStripe(v, dom); >>> (* Paint the scroll. We are careful not to draw the area of the >>> trough that will be covered by the stripe. This helps reduce >>> the flicker. *) >>> r := Rect.Inset(dom, v.shadowPixels); >>> ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Lowered, >>> r, dom); >>> Rect.Factor(r, stripe, f, 0, 0); >>> FOR i := FIRST(f) TO LAST(f) DO >>> IF i # 2 AND NOT Rect.IsEmpty(f[i]) THEN >>> VBT.PaintTint(v, f[i], v.troughColor); >>> END; >>> END; >>> (* Paint the stripe. *) >>> r := Rect.Inset(stripe, v.shadowPixels); >>> ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, >>> r, stripe); >>> VBT.PaintTint(v, r, v.shadow.bg); >>> END PaintViewWithShadows; >>> >>> >>> I'm somewhat just showing people how to get started debugging it, >>> in case folks are as afraid of command line debuggers as I used to >>> be. >>> >>> >>> - Jay >> From wagner at elegosoft.com Fri Mar 20 08:09:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Mar 2009 08:09:26 +0100 Subject: [M3devel] formsedit crash during startup sometimes? In-Reply-To: References: Message-ID: <20090320080926.7b6ishzqs8w4k4g4@mail.elegosoft.com> Quoting Jay : > Wouldn't it be super cool, though if I could just issue one command, > wait overnight or whatever, and voila, several of those builds > done, in both directions, just awaiting human test/observation? > Yeah.. > > I don't even know how yet to sync an entire CVS tree to a date yet, > maybe cvs upd -d? > (Nice thing about 5.4.0 is I don't need CVS to identify it.) It's the capital D and easily available in online help: % cvs co -h co: invalid option -- h Usage: cvs checkout [-ANPRcflnps] [-r rev] [-D date] [-d dir] [-j rev1] [-j rev2] [-k kopt] modules... -A Reset any sticky tags/date/kopts. -N Don't shorten module paths if -d specified. -P Prune empty directories. -R Process directories recursively. -c "cat" the module database. -f Force a head revision match if tag/date not found. -l Local directory only, not recursive -n Do not run module program (if any). -p Check out files to standard output (avoids stickiness). -s Like -c, but include module status. -r rev Check out revision or tag. (implies -P) (is sticky) -D date Check out revisions as of date. (implies -P) (is sticky) -d dir Check out into dir instead of module name. -k kopt Use RCS kopt -k option on checkout. (is sticky) -j rev Merge in changes made between current revision and rev. (Specify the --help global option for a list of other help options) luthien [~] wagner % cvs update -h update: invalid option -- h Usage: cvs update [-APCdflRp] [-k kopt] [-r rev] [-D date] [-j rev] [-I ign] [-W spec] [files...] -A Reset any sticky tags/date/kopts. -P Prune empty directories. -C Overwrite locally modified files with clean repository copies. -d Build directories, like checkout does. -f Force a head revision match if tag/date not found. -l Local directory only, no recursion. -R Process directories recursively. -p Send updates to standard output (avoids stickiness). -k kopt Use RCS kopt -k option on checkout. (is sticky) -r rev Update using specified revision/tag (is sticky). -D date Set date to update from (is sticky). -j rev Merge in changes made between current revision and rev. -I ign More files to ignore (! to reset). -W spec Wrappers specification line. (Specify the --help global option for a list of other help options) Usually it's better to use tags instead of dates, since the latter need not identify a consistent configuration, but for your purpose it should be OK. Information about CVS is available from a number of online sources. freebsd.org offers a nice possibility to read manual pages online for example: http://www.freebsd.org/cgi/man.cgi?query=cvs&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE&format=html Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Mar 20 14:14:36 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 20 Mar 2009 09:14:36 -0400 Subject: [M3devel] trestle protability Message-ID: <20090320131436.GA4463@topoi.pooq.com> I'm planning an application (kind of a a pixel editor with variable-sized pixels) that has to do mouse tracking. Now that's available in Trestle, so (in principle) no problem there. But this program, ideally, should run on both Linux and Windows. So I ask: do the Windows version(s) of modula3 have sufficiently compatible implementations of Trestle? I have limited resources for debugging Windows code; ideally no source-code change would be required. If not, are there other UI libraries available fo Midula 3 that *are* compatible? -- hendrik From mika at async.caltech.edu Fri Mar 20 15:34:56 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Mar 2009 07:34:56 -0700 Subject: [M3devel] trestle protability In-Reply-To: Your message of "Fri, 20 Mar 2009 09:14:36 EDT." <20090320131436.GA4463@topoi.pooq.com> Message-ID: <200903201434.n2KEYuBg036310@camembert.async.caltech.edu> It should work. I get a window popping up and then a crash in ThreadWin32.m3 when I try to run mentor on a win2k machine, but I'm using PM3/Klagenfurt... surely the new code works better :-) hendrik at topoi.pooq.com writes: >I'm planning an application (kind of a a pixel editor with >variable-sized pixels) that has to do mouse tracking. Now that's >available in Trestle, so (in principle) no problem there. But this >program, ideally, should run on both Linux and Windows. So I ask: do >the Windows version(s) of modula3 have sufficiently compatible >implementations of Trestle? I have limited resources for debugging >Windows code; ideally no source-code change would be required. > >If not, are there other UI libraries available fo Midula 3 that *are* >compatible? > >-- hendrik From mika at async.caltech.edu Fri Mar 20 15:36:03 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Mar 2009 07:36:03 -0700 Subject: [M3devel] trestle protability In-Reply-To: Your message of "Fri, 20 Mar 2009 09:14:36 EDT." <20090320131436.GA4463@topoi.pooq.com> Message-ID: <200903201436.n2KEa3J3036438@camembert.async.caltech.edu> And mentor works great on a win 2003 server system.... even with PM3/Klagenfurt. So you should be OK... hendrik at topoi.pooq.com writes: >I'm planning an application (kind of a a pixel editor with >variable-sized pixels) that has to do mouse tracking. Now that's >available in Trestle, so (in principle) no problem there. But this >program, ideally, should run on both Linux and Windows. So I ask: do >the Windows version(s) of modula3 have sufficiently compatible >implementations of Trestle? I have limited resources for debugging >Windows code; ideally no source-code change would be required. > >If not, are there other UI libraries available fo Midula 3 that *are* >compatible? > >-- hendrik From rcoleburn at scires.com Fri Mar 20 18:50:01 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 20 Mar 2009 13:50:01 -0400 Subject: [M3devel] trestle protability In-Reply-To: <20090320131436.GA4463@topoi.pooq.com> References: <20090320131436.GA4463@topoi.pooq.com> Message-ID: <49C39E6D.1E75.00D7.1@scires.com> Hendrik: I've been using Trestle and FormsVBT on Windows for years. I've got such programs that run on both HPUX and Windows. Regards, Randy >>> 3/20/2009 9:14 AM >>> I'm planning an application (kind of a a pixel editor with variable-sized pixels) that has to do mouse tracking. Now that's available in Trestle, so (in principle) no problem there. But this program, ideally, should run on both Linux and Windows. So I ask: do the Windows version(s) of modula3 have sufficiently compatible implementations of Trestle? I have limited resources for debugging Windows code; ideally no source-code change would be required. If not, are there other UI libraries available fo Midula 3 that *are* compatible? -- hendrik CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Mar 23 18:37:34 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Mar 2009 10:37:34 -0700 (PDT) Subject: [M3devel] About 404 http https error at opencm3.net elegosoft.com modula3.org Message-ID: <577748.77637.qm@web24706.mail.ird.yahoo.com> Hi all: just want to make sure I can't access? the web pages of the server. Is it working well ? on https://elegosoft.com/ or http://elegosoft.com/ I got 404 error from the common urls Not Found The requested URL / was not found on this server. Apache Server at www.opencm3.net Port 80 However server does respond to ICMP requests and I guess other services (including http) ping opencm3.net PING opencm3.net (88.198.39.217) 56(84) bytes of data. 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=1 ttl=54 time=117 ms 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=2 ttl=54 time=115 ms 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=3 ttl=54 time=115 ms 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=4 ttl=54 time=115 ms 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=5 ttl=54 time=115 ms 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=6 ttl=54 time=115 ms --- opencm3.net ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 4998ms rtt min/avg/max/mdev = 115.483/115.854/117.030/0.578 ms And I can't get any web page on http or https wget opencm3.net --12:08:02--? http://opencm3.net/ ?????????? => `index.html' Resolving opencm3.net... 88.198.39.217 Connecting to opencm3.net|88.198.39.217|:80... connected. HTTP request sent, awaiting response... 404 Not Found 12:08:02 ERROR 404: Not Found. wget https://opencm3.net --no-check-certificate --12:13:25--? https://opencm3.net/ ?????????? => `index.html' Resolving opencm3.net... 88.198.39.217 Connecting to opencm3.net|88.198.39.217|:443... connected. WARNING: Certificate verification error for opencm3.net: self signed certificate in certificate chain WARNING: certificate common name `wiki.elegosoft.com' doesn't match requested host name `opencm3.net'. HTTP request sent, awaiting response... 404 Not Found 12:13:25 ERROR 404: Not Found. I can't rememeber now my elego.de user passsword so I can't diagnose further more. Can any one check further on the web server? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Mon Mar 23 20:32:41 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Mon, 23 Mar 2009 20:32:41 +0100 Subject: [M3devel] About 404 http https error at opencm3.net elegosoft.com modula3.org In-Reply-To: <577748.77637.qm@web24706.mail.ird.yahoo.com> References: <577748.77637.qm@web24706.mail.ird.yahoo.com> Message-ID: <20090323203241.25qdopfjksocc4s8@mail.elegosoft.com> Hello All, birch.elego.de experienced a hardware failure today. I am in the process of rebuilding and restoring now. I hope to get web services up soon. Thanks for your patience. -Michael Anderson Quoting "Daniel Alejandro Benavides D." : > Hi all: > just want to make sure I can't access? the web pages of the server. > Is it working well ? > on https://elegosoft.com/ > or http://elegosoft.com/ > I got 404 error from the common urls > Not Found > The requested URL / was not found on this server. > > Apache Server at www.opencm3.net Port 80 > > However server does respond to ICMP requests and I guess other > services (including http) > ping opencm3.net > PING opencm3.net (88.198.39.217) 56(84) bytes of data. > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=1 ttl=54 time=117 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=2 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=3 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=4 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=5 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=6 ttl=54 time=115 ms > > --- opencm3.net ping statistics --- > 6 packets transmitted, 6 received, 0% packet loss, time 4998ms > rtt min/avg/max/mdev = 115.483/115.854/117.030/0.578 ms > > And I can't get any web page on http or https > > wget opencm3.net > --12:08:02--? http://opencm3.net/ > ?????????? => `index.html' > Resolving opencm3.net... 88.198.39.217 > Connecting to opencm3.net|88.198.39.217|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 12:08:02 ERROR 404: Not Found. > > > > wget https://opencm3.net --no-check-certificate > --12:13:25--? https://opencm3.net/ > ?????????? => `index.html' > Resolving opencm3.net... 88.198.39.217 > Connecting to opencm3.net|88.198.39.217|:443... connected. > WARNING: Certificate verification error for opencm3.net: self signed > certificate in certificate chain > WARNING: certificate common name `wiki.elegosoft.com' doesn't match > requested host name `opencm3.net'. > HTTP request sent, awaiting response... 404 Not Found > 12:13:25 ERROR 404: Not Found. > > > I can't rememeber now my elego.de user passsword so I can't diagnose > further more. > Can any one check further on the web server? > > Thanks in advance > > > > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Mon Mar 23 21:57:54 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Mar 2009 13:57:54 -0700 (PDT) Subject: [M3devel] About 404 http https error at opencm3.net elegosoft.com modula3.org In-Reply-To: <20090323203241.25qdopfjksocc4s8@mail.elegosoft.com> Message-ID: <917618.29859.qm@web24712.mail.ird.yahoo.com> Hi: thanks Michael, please if you can give us a note when is solved. Just to know. Thanks in advance --- El lun, 23/3/09, Michael Anderson escribi?: De: Michael Anderson Asunto: Re: [M3devel] About 404 http https error at opencm3.net elegosoft.com modula3.org Para: m3devel at elegosoft.com Fecha: lunes, 23 marzo, 2009 2:32 Hello All, birch.elego.de experienced a hardware failure today. I am in the process of rebuilding and restoring now. I hope to get web services up soon. Thanks for your patience. -Michael Anderson Quoting "Daniel Alejandro Benavides D." : > Hi all: > just want to make sure I can't access? the web pages of the server. Is it working well ? > on https://elegosoft.com/ > or http://elegosoft.com/ > I got 404 error from the common urls > Not Found > The requested URL / was not found on this server. > > Apache Server at www.opencm3.net Port 80 > > However server does respond to ICMP requests and I guess other services (including http) > ping opencm3.net > PING opencm3.net (88.198.39.217) 56(84) bytes of data. > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=1 ttl=54 time=117 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=2 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=3 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=4 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=5 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=6 ttl=54 time=115 ms > > --- opencm3.net ping statistics --- > 6 packets transmitted, 6 received, 0% packet loss, time 4998ms > rtt min/avg/max/mdev = 115.483/115.854/117.030/0.578 ms > > And I can't get any web page on http or https > > wget opencm3.net > --12:08:02--? http://opencm3.net/ > ?????????? => `index.html' > Resolving opencm3.net... 88.198.39.217 > Connecting to opencm3.net|88.198.39.217|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 12:08:02 ERROR 404: Not Found. > > > > wget https://opencm3.net --no-check-certificate > --12:13:25--? https://opencm3.net/ > ?????????? => `index.html' > Resolving opencm3.net... 88.198.39.217 > Connecting to opencm3.net|88.198.39.217|:443... connected. > WARNING: Certificate verification error for opencm3.net: self signed certificate in certificate chain > WARNING: certificate common name `wiki.elegosoft.com' doesn't match requested host name `opencm3.net'. > HTTP request sent, awaiting response... 404 Not Found > 12:13:25 ERROR 404: Not Found. > > > I can't rememeber now my elego.de user passsword so I can't diagnose further more. > Can any one check further on the web server? > > Thanks in advance > > > > --Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Mar 25 08:31:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 25 Mar 2009 08:31:58 +0100 Subject: [M3devel] m3 CVS? In-Reply-To: References: Message-ID: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> Quoting Jay : > > Any idea when CVS will be back? > And what state it will be in? There was a bad disk crash on birch, and some of the backups (rootfs) seem to be unusable, so it's taking longer than expected. All CM3 CVS data should be save. Sorry for the service interruption, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Wed Mar 25 14:52:34 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 09:52:34 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> Message-ID: <20090325135234.GA16351@topoi.pooq.com> On Wed, Mar 25, 2009 at 08:31:58AM +0100, Olaf Wagner wrote: > Quoting Jay : > > > > >Any idea when CVS will be back? > >And what state it will be in? > > There was a bad disk crash on birch, and some of the backups (rootfs) > seem to be unusable, so it's taking longer than expected. Ouch! I've had one of those. Now I use a RAID-1, regular backups onto USB drives I keep disconnected from the computer, and check important source code into a distributed revision control system with a complete copy of the archive on a remote site. All in all, three different backup technologies. Am I too paranoid? > All CM3 CVS data should be save. That's good. It looks as if you've been paranoid enough. > > Sorry for the service interruption, > > Olaf I just tried to access monotone.ca. ping monotone.ca works, but http: access is quite dead. At this point, I speculate it would be nice to have another server somewhere else in the world. When things are back together, I could experiment with setting up a monotone server with the same content and history as the Modula 3 CVS, if you like. monotone is a distributed version control system that is reported to have good interoperation with CVS. It would be interesting to test if that is actually true. No, you wouldn't have to switch from CVS to monotone if I did that. -- hendrik From hendrik at topoi.pooq.com Wed Mar 25 15:08:46 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 10:08:46 -0400 Subject: [M3devel] Am I experiencing garbage collection? Message-ID: <20090325140846.GA16459@topoi.pooq.com> I'm working on a pixel-based image edotor with variable-sized pixels. (That weirdness was the one of the simplest things that could possibly work for an esoteric application.) I implemented mouse-tracking according to instructins in the Trestle manual, and it works, except for small gaps that occur every few seconds. They correspond to mouse-deafness intervals of maybe a hundredth or a twentieth of a second or so. But in the course of building my pizel map, I find myself allocating storage dynamically. Could I be experiencing garbage-collection delays? -- hendrik From wagner at elegosoft.com Wed Mar 25 16:35:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 25 Mar 2009 16:35:37 +0100 Subject: [M3devel] m3 CVS? In-Reply-To: <20090325135234.GA16351@topoi.pooq.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> Message-ID: <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Mar 25, 2009 at 08:31:58AM +0100, Olaf Wagner wrote: >> Quoting Jay : >> > I just tried to access monotone.ca. ping monotone.ca works, but http: > access is quite dead. > > At this point, I speculate it would be nice to have another server > somewhere else in the world. The CM3 repository is replicated to several other machines every night via CVSup. But the other machines are not publicly accessible. > When things are back together, I could experiment with setting up a > monotone server with the same content and history as the Modula 3 CVS, > if you like. monotone is a distributed version control system that is > reported to have good interoperation with CVS. It would be interesting > to test if that is actually true. Yes. > No, you wouldn't have to switch from CVS to monotone if I did that. No objections at all. I wouldn't object to Subversion, too, if somebody would do all the work and provide the equivalent infrastructure. It's just that I don't see that we really need it. I'd like to see Hudson instead of Tinderbox though... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Wed Mar 25 15:45:06 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 10:45:06 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> Message-ID: <20090325144505.GA16526@topoi.pooq.com> On Wed, Mar 25, 2009 at 04:35:37PM +0100, Olaf Wagner wrote: > > >When things are back together, I could experiment with setting up a > >monotone server with the same content and history as the Modula 3 CVS, > >if you like. monotone is a distributed version control system that is > >reported to have good interoperation with CVS. It would be interesting > >to test if that is actually true. > > Yes. Further googling reveals that the encouraging messages about interoperability are a few years old, and refer to a non-trunk development branch. The next step would seem to be to figure out what the status of that work is now. I.m no longer quite as optimistic. There does seem to be a one-way conversino from CVS to monotone, but that's not what I'm looking for. -- hendrik > I'd like to see Hudson instead of Tinderbox though... What are these? -- hendrik From wagner at elegosoft.com Wed Mar 25 17:18:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 25 Mar 2009 17:18:55 +0100 Subject: [M3devel] m3 CVS? In-Reply-To: <20090325144505.GA16526@topoi.pooq.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> Message-ID: <20090325171855.24zpbw1lsg048g4c@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Mar 25, 2009 at 04:35:37PM +0100, Olaf Wagner wrote: > >> I'd like to see Hudson instead of Tinderbox though... > > What are these? Continuous integration or regression test frameworks. We currently use tinderbox on birch, but that hasn't really convinced me, though it's way better than nothing. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Wed Mar 25 21:16:00 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 25 Mar 2009 21:16:00 +0100 (CET) Subject: [M3devel] [Fwd: Prentice-Hall says no] In-Reply-To: <49C23A1F.1070800@bellsouth.net> References: <49C23A1F.1070800@bellsouth.net> Message-ID: The current lawsuit against Google might end with a settlement which may allow Google to make books available online that are out of print. Would this be a solution? http://www.googlebooksettlement.com/ From jay.krell at cornell.edu Wed Mar 25 22:44:11 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 25 Mar 2009 21:44:11 +0000 Subject: [M3devel] m3 CVS? In-Reply-To: <20090325144505.GA16526@topoi.pooq.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> Message-ID: /Apparently/ cvs to svn conversion is pretty easy and good. svn is not "distributed", but at least it automatically keeps originals locally so you can diff without accessing the server. And browsing history where multiple files are commited in one change works, vs. cvs. svn branching doesn't really work, but that's probaby ok. Maybe they have fixed it, but for a long time, svn would not know what changes had been moved to which branches, a pretty basic requirement. Perforce does this perfectly. Perforce might be a good option if being open source lets us get it for free. Otherwise it is expensive. It is an excellent product. svn is at least somewhat better than cvs. - Jay ---------------------------------------- > Date: Wed, 25 Mar 2009 10:45:06 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3 CVS? > > On Wed, Mar 25, 2009 at 04:35:37PM +0100, Olaf Wagner wrote: >> >>>When things are back together, I could experiment with setting up a >>>monotone server with the same content and history as the Modula 3 CVS, >>>if you like. monotone is a distributed version control system that is >>>reported to have good interoperation with CVS. It would be interesting >>>to test if that is actually true. >> >> Yes. > > Further googling reveals that the encouraging messages about > interoperability are a few years old, and refer to a non-trunk > development branch. The next step would seem to be to figure out what > the status of that work is now. I.m no longer quite as optimistic. > There does seem to be a one-way conversino from CVS to monotone, but > that's not what I'm looking for. > > -- hendrik > >> I'd like to see Hudson instead of Tinderbox though... > > What are these? > > -- hendrik From hosking at cs.purdue.edu Thu Mar 26 00:15:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Mar 2009 10:15:12 +1100 Subject: [M3devel] Fwd: Output from "cron" command References: <200903251030.n2PAUN5M001118@niagara.cs.purdue.edu> Message-ID: <3637619A-EFC4-4E00-A3E9-FDA11D8050E6@cs.purdue.edu> Something wrong with birch? Why would I suddenly be getting sudo errors? Begin forwarded message: > From: Tony Hosking > Date: 25 March 2009 21:30:23 GMT+11:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > Cannot access /usr/cvs/CVSROOT > No such file or directory > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-03-25-10-30-07 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090325-063009-dWaOYb/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.03.25 06:30:09 -- checkout in progress. > > We trust you have received the usual lecture from the local System > Administrator. It usually boils down to these three things: > > #1) Respect the privacy of others. > #2) Think before you type. > #3) With great power comes great responsibility. > > Password: > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090325-063009-dWaOYb ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > Cannot access /usr/cvs/CVSROOT > No such file or directory > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-03-25-10-30-17 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090325-063019-Okaiac/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.03.25 06:30:19 -- checkout in progress. > > We trust you have received the usual lecture from the local System > Administrator. It usually boils down to these three things: > > #1) Respect the privacy of others. > #2) Think before you type. > #3) With great power comes great responsibility. > > Password: > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090325-063019-Okaiac ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 26 00:23:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Mar 2009 10:23:24 +1100 Subject: [M3devel] Am I experiencing garbage collection? In-Reply-To: <20090325140846.GA16459@topoi.pooq.com> References: <20090325140846.GA16459@topoi.pooq.com> Message-ID: It is possible that you are experiencing delays, though I am surprised that you have user-noticeable delays. Do you have a demo I can try? You could also try turning of GC (@M3nogc) and see if the delays are no longer there. On 26 Mar 2009, at 01:08, hendrik at topoi.pooq.com wrote: > I'm working on a pixel-based image edotor with variable-sized pixels. > (That weirdness was the one of the simplest things that could possibly > work for an esoteric application.) > > I implemented mouse-tracking according to instructins in the Trestle > manual, and it works, except for small gaps that occur every few > seconds. They correspond to mouse-deafness intervals of maybe a > hundredth or a twentieth of a second or so. > > But in the course of building my pizel map, I find myself allocating > storage dynamically. Could I be experiencing garbage-collection > delays? > > -- hendrik From hendrik at topoi.pooq.com Wed Mar 25 23:54:21 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 18:54:21 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> Message-ID: <20090325225421.GB17118@topoi.pooq.com> On Wed, Mar 25, 2009 at 09:44:11PM +0000, Jay wrote: > > /Apparently/ cvs to svn conversion is pretty easy and good. conversion from cvs to monotone works, too. It's converting back from monotone to cvs that is apparently a problem. But I still haven't heard the current status of the cvssync branch of monotone development. That's the branch where monotone allegedly worked both ways with CVS. > > svn is not "distributed", but at least it automatically keeps > originals locally so you can diff without accessing the server. Being distributed, monotone keeps originals locally, too. And monotone will diff them for you. > > And browsing history where multiple files are commited > in one change works, vs. cvs. As does monotone, and many current VCSs. > > svn branching doesn't really work, but that's probaby ok. monotone branching does work. > Maybe they have fixed it, but for a long time, svn > would not know what changes had been moved to which branches, > a pretty basic requirement. Perforce does this perfectly. > Perforce might be a good option if being open source lets > us get it for free. Otherwise it is expensive. It is an > excellent product. > > svn is at least somewhat better than cvs. In http://gravityboy.livejournal.com/39755.html, gravityboy says : I'm really tired of people pushing the adoption of svn because it's a : better CVS. The only people who that argument hasn't swayed are those : who don't care what vcs they use, and that's because they don't : care about the argument. Despite its name, svn is the status quo now, : so do try to compare it to systems that it hasn't already made obsolete. Apparently he'd like to have svn compared to newer VCSs instead of obsolete ones. In case you don't know, gravityboy is one of the X developers that got X doing reasonable autodetection of hardware. I'm in awe of what that group accomplished. The thing I really like about monotone is that the developers are absolutely paranoid about data loss. It refuses to sync with broken repositories, and spends extra time on internal consistency checks on the data base during sync. This provides some protection against corruption due to bits dropped on hard disk and such. They have a rigorous and pragmatic attitude about correctness that I see in the Modula 3 design, too. Except that they developed monotone using C++. -- hendrik > > - Jay From hendrik at topoi.pooq.com Thu Mar 26 00:00:54 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 19:00:54 -0400 Subject: [M3devel] Am I experiencing garbage collection? In-Reply-To: References: <20090325140846.GA16459@topoi.pooq.com> Message-ID: <20090325230053.GC17118@topoi.pooq.com> On Thu, Mar 26, 2009 at 10:23:24AM +1100, Tony Hosking wrote: > It is possible that you are experiencing delays, though I am surprised > that you have user-noticeable delays. Do you have a demo I can try? > You could also try turning of GC (@M3nogc) and see if the delays are > no longer there. I don't notice a delay -- I notice small gaps in the trail of pixels activated by the mouse rolling over them. From the size of the gap I estimate it might be as long as a twentieth of a secind, but it's probably more like a hundredth. I didn't use a stopwatch to time it. And I do build a fair amount of data structure per pixel. I'm probably going to have to change it -- but only once I've got some experience how the application actually works. At the moment I've only ot a few bits and pieces. That option @M3nogc -- do I put it on the command line when I execute? -- hendrik From hendrik at topoi.pooq.com Thu Mar 26 00:14:38 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 19:14:38 -0400 Subject: [M3devel] Am I experiencing garbage collection? In-Reply-To: <20090325230053.GC17118@topoi.pooq.com> References: <20090325140846.GA16459@topoi.pooq.com> <20090325230053.GC17118@topoi.pooq.com> Message-ID: <20090325231437.GA17379@topoi.pooq.com> On Wed, Mar 25, 2009 at 07:00:54PM -0400, hendrik at topoi.pooq.com wrote: > On Thu, Mar 26, 2009 at 10:23:24AM +1100, Tony Hosking wrote: > > It is possible that you are experiencing delays, though I am surprised > > that you have user-noticeable delays. Do you have a demo I can try? > > You could also try turning of GC (@M3nogc) and see if the delays are > > no longer there. > > That option @M3nogc -- do I put it on the command line when I execute? Thanks. Running ./LINUXLIBC6/Main @M3nogc instead of ./LINUXLIBC6/Main gives me the same momentary gaps. So if that's how you shut off the garbage collector, it's not the garbage collector. Perhaps some other process is stealing centiseconds now and then. -- hendrik From hosking at cs.purdue.edu Thu Mar 26 01:26:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Mar 2009 11:26:55 +1100 Subject: [M3devel] Am I experiencing garbage collection? In-Reply-To: <20090325231437.GA17379@topoi.pooq.com> References: <20090325140846.GA16459@topoi.pooq.com> <20090325230053.GC17118@topoi.pooq.com> <20090325231437.GA17379@topoi.pooq.com> Message-ID: <27EB1179-F121-4DCA-8B4C-91136EA80DF6@cs.purdue.edu> That's good (from my perspective) because I worried the collector was getting in the way. Looks like something else perhaps. I suggest profiling somehow to get a sense as to what is interrupting you. Are you running with pthreads? On 26 Mar 2009, at 10:14, hendrik at topoi.pooq.com wrote: > On Wed, Mar 25, 2009 at 07:00:54PM -0400, hendrik at topoi.pooq.com > wrote: >> On Thu, Mar 26, 2009 at 10:23:24AM +1100, Tony Hosking wrote: >>> It is possible that you are experiencing delays, though I am >>> surprised >>> that you have user-noticeable delays. Do you have a demo I can try? >>> You could also try turning of GC (@M3nogc) and see if the delays are >>> no longer there. >> >> That option @M3nogc -- do I put it on the command line when I >> execute? > > Thanks. > > Running > ./LINUXLIBC6/Main @M3nogc > instead of > ./LINUXLIBC6/Main > gives me the same momentary gaps. So if that's how you shut off the > garbage collector, it's not the garbage collector. Perhaps some other > process is stealing centiseconds now and then. > > -- hendrik From hendrik at topoi.pooq.com Thu Mar 26 01:43:07 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 20:43:07 -0400 Subject: [M3devel] Am I experiencing garbage collection? In-Reply-To: <27EB1179-F121-4DCA-8B4C-91136EA80DF6@cs.purdue.edu> References: <20090325140846.GA16459@topoi.pooq.com> <20090325230053.GC17118@topoi.pooq.com> <20090325231437.GA17379@topoi.pooq.com> <27EB1179-F121-4DCA-8B4C-91136EA80DF6@cs.purdue.edu> Message-ID: <20090326004307.GA17514@topoi.pooq.com> On Thu, Mar 26, 2009 at 11:26:55AM +1100, Tony Hosking wrote: > That's good (from my perspective) because I worried the collector was > getting in the way. Looks like something else perhaps. I suggest > profiling somehow to get a sense as to what is interrupting you. Are > you running with pthreads? I don't know whether I'm using pthreads. I just grabbed the source from the web site and compiled for a while. Critical Mass Modula-3 version d5.7.0 last updated: 2008-03-16 compiled: 2008-04-09 01:32:11 configuration: /usr/local/cm3/bin/cm3.cfg Anyway, pthreads or not, my process isn't the only one on the machine. And there's easy application-dependent workarounds. And some changes I have to make for other reasons will probably bypass the problem I'm having now anyway. Let me say that your surprise at the thought that the garbage collector could be causing these interruptions is a strong indication that I won't have to worry about collection delays. -- hendrik From jay.krell at cornell.edu Thu Mar 26 03:08:00 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 26 Mar 2009 02:08:00 +0000 Subject: [M3devel] m3 CVS? In-Reply-To: <20090325225421.GB17118@topoi.pooq.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> Message-ID: > > svn is at least somewhat better than cvs. > > In http://gravityboy.livejournal.com/39755.html, gravityboy says > > : I'm really tired of people pushing the adoption of svn because it's a > : better CVS. The only people who that argument hasn't swayed are those That's ambiguous to me. He isn't clearly opposed to adopting svn over cvs, but svn over anything else. It doesn't matter what I think, but I'm definitely not opposed to monotone. Its marketing material reads among the best (seriously). I'm not volunteering to do any conversion, and I'm sure I (and others) will grumble no matter how painless switching clients is, but I'm pretty sure there are gains to be had and ignore at least my grumbling. I really don't like the web interface to CVS in particular. It doesn't let me identify "change sets" and view their diffs, I have to root around to all the files. Tinderbox does address this, on the side. (You would have to be sure, whatever replacement/conversion, included a web interface, anonymous read-only access, Tinderbox-or-other interop, etc.; imho you don't have to deliver all at once.) The source control systems that use "databases", which I think monotone does, do they interact poorly with backup (in particular, whatever backup Elegosoft uses)? You know -- an incremental backup system that looks at file times/sizes would end up always copying the entire thing. Even so, "databases" can be a good thing.. I understand that "two way migration" lets people keep using either system, but I'm not sure that's worthwhile. On the other hand, if "the new way" is read/write, and a "cvs mirror" is read only, except for some blessed mirroring server, that should be fairly easy and have some value. That can also be a way to ease the transition wrt anonymous read-only access, Tinderbox interop, etc. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 26 03:11:53 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 26 Mar 2009 02:11:53 +0000 Subject: [M3devel] Am I experiencing garbage collection? In-Reply-To: <20090326004307.GA17514@topoi.pooq.com> References: <20090325140846.GA16459@topoi.pooq.com> <20090325230053.GC17118@topoi.pooq.com> <20090325231437.GA17379@topoi.pooq.com> <27EB1179-F121-4DCA-8B4C-91136EA80DF6@cs.purdue.edu> <20090326004307.GA17514@topoi.pooq.com> Message-ID: pthreads is the default, and I suspect it is the only thing that works currently. I started debugging why it wasn't working on PPC_LINUX, the reason seemed to be that the initial thread was used before it was allocated, but I stopped debugging and just switched to pthreads. NetBSD/x86 didn't work as it was -- didn't even compile I think -- so I switched it to pthreads as well. (I'll have a NetBSD/x86 archive up very soon.) I might go back and debug these again.. - Jay > Date: Wed, 25 Mar 2009 20:43:07 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Am I experiencing garbage collection? > > On Thu, Mar 26, 2009 at 11:26:55AM +1100, Tony Hosking wrote: > > That's good (from my perspective) because I worried the collector was > > getting in the way. Looks like something else perhaps. I suggest > > profiling somehow to get a sense as to what is interrupting you. Are > > you running with pthreads? > > I don't know whether I'm using pthreads. I just grabbed the source > from the web site and compiled for a while. > > Critical Mass Modula-3 version d5.7.0 > last updated: 2008-03-16 > compiled: 2008-04-09 01:32:11 > configuration: /usr/local/cm3/bin/cm3.cfg > > Anyway, pthreads or not, my process isn't the only one on the machine. > > And there's easy application-dependent workarounds. And some changes I > have to make for other reasons will probably bypass the problem > I'm having now anyway. > > Let me say that your surprise at the thought that the garbage collector > could be causing these interruptions is a strong indication that I > won't have to worry about collection delays. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 26 11:04:50 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 26 Mar 2009 10:04:50 +0000 Subject: [M3devel] ports with versions in their names? Message-ID: These platforms..NetBSD2i386, FreeBSD4..in particular because they identify old versions, should we just pretend they are "I386_NETBSD" and "I386_FREEBSD"? Introduce new platforms with those names? Current FreeBSD is 7.1, though I know 4.0 might be more popular than it sounds. There is not likely anything any longer version specific in the source to these ports, and possibly not even in the binaries. And if there is anything version-specific in the binaries, removing it might requiring building on the particular host, or at least capturing their sysroot and building cross gcc/ld/gas. I don't know if the "6" in "LINUXLIBC6" still makes sense. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Mar 26 14:22:17 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 26 Mar 2009 14:22:17 +0100 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <3637619A-EFC4-4E00-A3E9-FDA11D8050E6@cs.purdue.edu> References: <200903251030.n2PAUN5M001118@niagara.cs.purdue.edu> <3637619A-EFC4-4E00-A3E9-FDA11D8050E6@cs.purdue.edu> Message-ID: <20090326142217.po81adh5yccs0kck@mail.elegosoft.com> Quoting Tony Hosking : > Something wrong with birch? Why would I suddenly be getting sudo errors? Birch has had a root file system disk crash. Michael Anderson is taking care. I just asked him to write a short status mail about the recovery activites and when all services should be available again. All CVS data should be safe, but may not yet be online again. Sorry for the inconveniences, Olaf > Begin forwarded message: > >> From: Tony Hosking >> Date: 25 March 2009 21:30:23 GMT+11:00 >> To: hosking at cs.purdue.edu >> Subject: Output from "cron" command >> >> Your "cron" job on niagara.cs.purdue.edu >> $HOME/cm3/scripts/regression/cron.sh >> >> produced the following output: >> >> Cannot access /usr/cvs/CVSROOT >> No such file or directory >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-03-25-10-30-07 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >> >> creating log file /tmp/build-cm3-20090325-063009-dWaOYb/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.03.25 06:30:09 -- checkout in progress. >> >> We trust you have received the usual lecture from the local System >> Administrator. It usually boils down to these three things: >> >> #1) Respect the privacy of others. >> #2) Think before you type. >> #3) With great power comes great responsibility. >> >> Password: >> Error: Sending buildlog failed! >> removing build tree /tmp/build-cm3-20090325-063009-dWaOYb ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> >> Cannot access /usr/cvs/CVSROOT >> No such file or directory >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-03-25-10-30-17 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >> >> creating log file /tmp/build-cm3-20090325-063019-Okaiac/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.03.25 06:30:19 -- checkout in progress. >> >> We trust you have received the usual lecture from the local System >> Administrator. It usually boils down to these three things: >> >> #1) Respect the privacy of others. >> #2) Think before you type. >> #3) With great power comes great responsibility. >> >> Password: >> Error: Sending buildlog failed! >> removing build tree /tmp/build-cm3-20090325-063019-Okaiac ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From michael.anderson at elego.de Fri Mar 27 06:07:52 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 27 Mar 2009 06:07:52 +0100 Subject: [M3devel] Modula3.org Server Crash Message-ID: <20090327060752.unn6c683wo88kww0@mail.elegosoft.com> Hello Modula3 Users, Developers, Earlier this week, our Modula3 development and web server birch.elegosoft.com suffered a sudden and catastrophic hard drive failure, coinciding with a problem of unrelated origins which rendered a portion of our filesystem backups unusable. The status of birch now: -The cm3 cvs repository is safe, intact, and back online. The data is up to date, but configuration is not quite as current and will need some tweaking. Commit email notifications aren't working quite right yet. If anybody happens to have a halfway recently checked-out /usr/local/CVSROOT, I'd love to get my hands on it. -The cvs pserver is available and cvsweb is up. -The website is up, albeit with a considerable number of broken links, which will be repaired as other services and data come online. -I'll be working on Tinderbox next. I'm hoping to get everything halfway back to normal by early next week. Sorry for the chaos, thanks for being patient. -Michael Anderson -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Mar 27 08:23:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Mar 2009 08:23:37 +0100 Subject: [M3devel] ports with versions in their names? In-Reply-To: References: Message-ID: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> Quoting Jay : > > These platforms..NetBSD2i386, FreeBSD4..in particular > because they identify old versions, should we just > pretend they are "I386_NETBSD" and "I386_FREEBSD"? > > Introduce new platforms with those names? The names seem OK; if you want to rename, this will of course cause some trouble, but I wouldn't object. Perhaps adding them and then slowly phasing out the old platforms will work best. > Current FreeBSD is 7.1, though I know 4.0 might be > more popular than it sounds. FreeBSD 4 perhaps still has its users, as has FreeBSD6 (am still running that myself). We'll need to provide different binary archives for those platforms then (further differentiation in archive names is needed). > There is not likely anything any longer version specific > in the source to these ports, and possibly not even in the binaries. I'd doubt that. At least FreeBSD has always changed its APIs and even ABIs between major releases. Recompilation of C sources _will_ be needed. > And if there is anything version-specific in the binaries, > removing it might requiring building on the particular host, > or at least capturing their sysroot and building cross gcc/ld/gas. > > I don't know if the "6" in "LINUXLIBC6" still makes sense. Perhaps just reuse the long obsolet LINUX then? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Fri Mar 27 21:33:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 27 Mar 2009 13:33:24 -0700 Subject: [M3devel] ports with versions in their names? In-Reply-To: Your message of "Fri, 27 Mar 2009 08:23:37 BST." <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> Message-ID: <200903272033.n2RKXOci055168@camembert.async.caltech.edu> Olaf Wagner writes: >Quoting Jay : > >> >> These platforms..NetBSD2i386, FreeBSD4..in particular >> because they identify old versions, should we just >> pretend they are "I386_NETBSD" and "I386_FREEBSD"? >> >> Introduce new platforms with those names? > >The names seem OK; if you want to rename, this will of course >cause some trouble, but I wouldn't object. Perhaps adding >them and then slowly phasing out the old platforms will work >best. > >> Current FreeBSD is 7.1, though I know 4.0 might be >> more popular than it sounds. > >FreeBSD 4 perhaps still has its users, as has FreeBSD6 (am still >running that myself). >We'll need to provide different binary archives for those platforms >then (further differentiation in archive names is needed). > >> There is not likely anything any longer version specific >> in the source to these ports, and possibly not even in the binaries. > >I'd doubt that. At least FreeBSD has always changed its APIs and even >ABIs between major releases. Recompilation of C sources _will_ be >needed. > Hi M3ers, As I think I've mentioned before, FreeBSD tends to be very well backward-compatible. If you have compat libraries installed that is. What this means is that you can take an old compiler binary and generate code that will run on the newer system. You cannot go backwards! So while you might be able to install SRC M3 for FreeBSD2 on a new system, you can't expect a FreeBSD7 binary dist to work even on a FreeBSD 6.x system. This is very different from the situation on Linux where things to break somewhat gradually in both directions. I still run at least one machine that's 4.11 and I use the exact same compiler binaries on 5.5. I'd be happy to volunteer to put together a binary distribution for FreeBSD4 when there's a new release of CM3. Mika P.S. of course my comments apply only to a single architecture. You can't go from FreeBSD2 on i386 to FreeBSD6 on amd64, I don't think. From jay.krell at cornell.edu Sat Mar 28 08:08:10 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 28 Mar 2009 07:08:10 +0000 Subject: [M3devel] ports with versions in their names? In-Reply-To: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> References: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> Message-ID: > > I don't know if the "6" in "LINUXLIBC6" still makes sense. > > Perhaps just reuse the long obsolet LINUX then? > > Olaf Given {AMD64,SPARC32,SPARC64,PPC,potentially PPC64,ALPHA,ARM,SH,MIPS32,MIPS64}_LINUX, doesn't it seem wrong to use plain "LINUX"? I know I know most of the world hasn't seen or heard of anything besides x86.. and "64bit" means AMD64... if we just had "LINUX" and "LINUX64" hardly anyone would see a problem.. More later.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Mar 28 11:11:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 28 Mar 2009 11:11:50 +0100 Subject: [M3devel] ports with versions in their names? In-Reply-To: References: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> Message-ID: <20090328111150.u81eq67aos08scwg@mail.elegosoft.com> Quoting Jay : >> > I don't know if the "6" in "LINUXLIBC6" still makes sense. >> >> Perhaps just reuse the long obsolet LINUX then? > > Given {AMD64,SPARC32,SPARC64,PPC,potentially > PPC64,ALPHA,ARM,SH,MIPS32,MIPS64}_LINUX, doesn't it seem wrong to > use plain "LINUX"? > > I know I know most of the world hasn't seen or heard of anything > besides x86.. and "64bit" means AMD64... if we just had "LINUX" and > "LINUX64" hardly anyone would see a problem.. Sorry, small misunderstanding. I didn't want to omit all architecture/ processor information, just leave out the LIBC6. So perhaps LINUX_MIPS32 or LINUX_AMD64 etc. would suffice? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Mar 28 13:04:01 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 28 Mar 2009 12:04:01 +0000 Subject: [M3devel] ports with versions in their names? In-Reply-To: <20090328111150.u81eq67aos08scwg@mail.elegosoft.com> References: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> <20090328111150.u81eq67aos08scwg@mail.elegosoft.com> Message-ID: Tony has established consistency around ARCH_KERNEL. I386_DARWIN PPC_DARWIN AMD64_DARWIN I followed that -- I like it and Tony said to -- but have been putting "32" in things, like: AMD64_FREEBSD AMD64_LINUX SPARC32_LINUX SPARC64_LINUX SPARC64_SOLARIS PPC32_OPENBSD I386_SOLARIS MIP64_OPENBSD etc. I realize some platforms had it the other the other way around. NetBSDi386v2 and a bunch in the ezm3 distribution and FSBD_ALPHA. But, I carefully only asked about platforms with versions in their names, which are clearly dubious, not about the more general issue of naming stuff. If Linux is "permanently" on libc 6.x, like the kernel is permanently 2.6.x, then my question/argument holds less/no water -- that's why I stated that way and made it "stronger" "against" NetBSD and FreeBSD, where I know the version history much better. (I understand, I think, part of the history. I think Linux had its own C runtime, and that got up to around version 5.x. And then there was a big switch to glibc, since that came after "linux libc 5.x", natural to call it 6. Though in reality I think the glibc version is 2.x..maybe it should have been called LINUXGLIBC..? It is mostly moot now, that's not likely to be a name introduced at this point..though there are currently multiple viable C runtimes on Linux -- uclibc, newlib, dietlibc..) - Jay > Date: Sat, 28 Mar 2009 11:11:50 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] ports with versions in their names? > > Quoting Jay : > > >> > I don't know if the "6" in "LINUXLIBC6" still makes sense. > >> > >> Perhaps just reuse the long obsolet LINUX then? > > > > Given {AMD64,SPARC32,SPARC64,PPC,potentially > > PPC64,ALPHA,ARM,SH,MIPS32,MIPS64}_LINUX, doesn't it seem wrong to > > use plain "LINUX"? > > > > I know I know most of the world hasn't seen or heard of anything > > besides x86.. and "64bit" means AMD64... if we just had "LINUX" and > > "LINUX64" hardly anyone would see a problem.. > > Sorry, small misunderstanding. I didn't want to omit all architecture/ > processor information, just leave out the LIBC6. So perhaps > LINUX_MIPS32 or LINUX_AMD64 etc. would suffice? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Mar 28 14:48:52 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 28 Mar 2009 13:48:52 +0000 Subject: [M3devel] Modula3.org Server Crash In-Reply-To: <20090327060752.unn6c683wo88kww0@mail.elegosoft.com> References: <20090327060752.unn6c683wo88kww0@mail.elegosoft.com> Message-ID: Commit seems to work (I get email) but also tells me: cvs commit: warning: cannot open history file `/usr/cvs/CVSROOT/history' for wri te: Permission denied cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. - Jay ---------------------------------------- > Date: Fri, 27 Mar 2009 06:07:52 +0100 > From: michael.anderson at elego.de > To: m3devel at elegosoft.com; m3announce at elegosoft.com; m3commit at elegosoft.com > Subject: [M3devel] Modula3.org Server Crash > > Hello Modula3 Users, Developers, > > Earlier this week, our Modula3 development and web server > birch.elegosoft.com suffered a sudden and catastrophic hard drive > failure, coinciding with a problem of unrelated origins which rendered > a portion of our filesystem backups unusable. > > The status of birch now: > > -The cm3 cvs repository is safe, intact, and back online. The data is > up to date, but configuration is not quite as current and will need > some tweaking. Commit email notifications aren't working quite right > yet. If anybody happens to have a halfway recently checked-out > /usr/local/CVSROOT, I'd love to get my hands on it. > > -The cvs pserver is available and cvsweb is up. > > -The website is up, albeit with a considerable number of broken links, > which will be repaired as other services and data come online. > > -I'll be working on Tinderbox next. > > I'm hoping to get everything halfway back to normal by early next week. > Sorry for the chaos, thanks for being patient. > > -Michael Anderson > > > > > > > -- > Michael Anderson > IT Services & Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Building 12.3 (BIG) room 227 > 13355 Berlin, Germany > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > fax +49 30 23 45 86 95 http://www.elegosoft.com > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > From michael.anderson at elego.de Sat Mar 28 22:00:32 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Sat, 28 Mar 2009 22:00:32 +0100 Subject: [M3devel] Modula3.org Server Crash In-Reply-To: References: <20090327060752.unn6c683wo88kww0@mail.elegosoft.com> Message-ID: <20090328220032.pe5isrci884sgsgs@mail.elegosoft.com> Hi Jay, I've adjusted the perms for the history file. The 'deprecated..' message is annoying but harmless. I will be tuning up the scripts in the course of the next couple of days. -Mike Quoting Jay : > > Commit seems to work (I get email) but also tells me: > > cvs commit: warning: cannot open history file > `/usr/cvs/CVSROOT/history' for wri > te: Permission denied > cvs commit: Using deprecated info format strings. Convert your > scripts to use > the new argument format and remove '1's from your info file format strings. > > - Jay > > > > ---------------------------------------- >> Date: Fri, 27 Mar 2009 06:07:52 +0100 >> From: michael.anderson at elego.de >> To: m3devel at elegosoft.com; m3announce at elegosoft.com; m3commit at elegosoft.com >> Subject: [M3devel] Modula3.org Server Crash >> >> Hello Modula3 Users, Developers, >> >> Earlier this week, our Modula3 development and web server >> birch.elegosoft.com suffered a sudden and catastrophic hard drive >> failure, coinciding with a problem of unrelated origins which rendered >> a portion of our filesystem backups unusable. >> >> The status of birch now: >> >> -The cm3 cvs repository is safe, intact, and back online. The data is >> up to date, but configuration is not quite as current and will need >> some tweaking. Commit email notifications aren't working quite right >> yet. If anybody happens to have a halfway recently checked-out >> /usr/local/CVSROOT, I'd love to get my hands on it. >> >> -The cvs pserver is available and cvsweb is up. >> >> -The website is up, albeit with a considerable number of broken links, >> which will be repaired as other services and data come online. >> >> -I'll be working on Tinderbox next. >> >> I'm hoping to get everything halfway back to normal by early next week. >> Sorry for the chaos, thanks for being patient. >> >> -Michael Anderson >> >> >> >> >> >> >> -- >> Michael Anderson >> IT Services & Support >> >> elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 >> Building 12.3 (BIG) room 227 >> 13355 Berlin, Germany >> >> phone +49 30 23 45 86 96 michael.anderson at elegosoft.com >> fax +49 30 23 45 86 95 http://www.elegosoft.com >> >> Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin >> Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 >> >> -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Mar 28 22:26:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 29 Mar 2009 08:26:16 +1100 Subject: [M3devel] ports with versions in their names? In-Reply-To: References: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> Message-ID: <907C9405-4720-4296-8139-004C72FA2CF2@cs.purdue.edu> LINUXx86? On 28 Mar 2009, at 18:08, Jay wrote: > > > I don't know if the "6" in "LINUXLIBC6" still makes sense. > > > > Perhaps just reuse the long obsolet LINUX then? > > > > Olaf > > > Given {AMD64,SPARC32,SPARC64,PPC,potentially > PPC64,ALPHA,ARM,SH,MIPS32,MIPS64}_LINUX, doesn't it seem wrong to > use plain "LINUX"? > > I know I know most of the world hasn't seen or heard of anything > besides x86.. and "64bit" means AMD64... if we just had "LINUX" and > "LINUX64" hardly anyone would see a problem.. > > More later.. > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Mar 28 22:27:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 29 Mar 2009 08:27:29 +1100 Subject: [M3devel] Fwd: Output from "cron" command References: <200903281030.n2SAUHeI003988@niagara.cs.purdue.edu> Message-ID: <8487DEE3-067D-463C-8C1E-E1FA0F37CC41@cs.purdue.edu> Still problems with tinderbox. Begin forwarded message: > From: Tony Hosking > Date: 28 March 2009 21:30:17 GMT+11:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > cvs checkout: warning: cannot open history file `/usr/cvs/CVSROOT/ > history' for write: Permission denied > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-03-28-10-30-04 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090328-063006-mEayzh/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.03.28 06:30:07 -- checkout in progress. > Content-type: text/html > > > [Sat Mar 28 11:30:09 2009] processmail_builds.cgi: Security Error. > Must not run this program using an effective user id which is > different than the tinderbox user id. id: 10006 id must be 33 > > > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090328-063006-mEayzh ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > cvs checkout: warning: cannot open history file `/usr/cvs/CVSROOT/ > history' for write: Permission denied > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-03-28-10-30-13 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090328-063015-TFa4Mh/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.03.28 06:30:15 -- checkout in progress. > Content-type: text/html > > > [Sat Mar 28 11:30:16 2009] processmail_builds.cgi: Security Error. > Must not run this program using an effective user id which is > different than the tinderbox user id. id: 10006 id must be 33 > > > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090328-063015-TFa4Mh ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Mar 28 22:31:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 29 Mar 2009 08:31:44 +1100 Subject: [M3devel] ports with versions in their names? In-Reply-To: References: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> <20090328111150.u81eq67aos08scwg@mail.elegosoft.com> Message-ID: <01BD9543-D2B1-4A3F-BFAE-5690BF928327@cs.purdue.edu> sounds good to me! On 28 Mar 2009, at 23:04, Jay wrote: > Tony has established consistency around ARCH_KERNEL. > I386_DARWIN > PPC_DARWIN > AMD64_DARWIN > > I followed that -- I like it and Tony said to -- but have been > putting "32" in things, like: > AMD64_FREEBSD > AMD64_LINUX > SPARC32_LINUX > SPARC64_LINUX > SPARC64_SOLARIS > PPC32_OPENBSD > I386_SOLARIS > MIP64_OPENBSD > etc. > > I realize some platforms had it the other the other way around. > NetBSDi386v2 and a bunch in the ezm3 distribution and FSBD_ALPHA. > > > But, I carefully only asked about platforms with versions in their > names, which are clearly dubious, not about the more general issue > of naming stuff. > > > If Linux is "permanently" on libc 6.x, like the kernel is > permanently 2.6.x, then my question/argument holds less/no water -- > that's why I stated that way and made it "stronger" "against" NetBSD > and FreeBSD, where I know the version history much better. > > > (I understand, I think, part of the history. I think Linux had its > own C runtime, and that got up to around version 5.x. And then there > was a big switch to glibc, since that came after "linux libc 5.x", > natural to call it 6. Though in reality I think the glibc version is > 2.x..maybe it should have been called LINUXGLIBC..? It is mostly > moot now, that's not likely to be a name introduced at this > point..though there are currently multiple viable C runtimes on > Linux -- uclibc, newlib, dietlibc..) > > > - Jay > > > > Date: Sat, 28 Mar 2009 11:11:50 +0100 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] ports with versions in their names? > > > > Quoting Jay : > > > > >> > I don't know if the "6" in "LINUXLIBC6" still makes sense. > > >> > > >> Perhaps just reuse the long obsolet LINUX then? > > > > > > Given {AMD64,SPARC32,SPARC64,PPC,potentially > > > PPC64,ALPHA,ARM,SH,MIPS32,MIPS64}_LINUX, doesn't it seem wrong to > > > use plain "LINUX"? > > > > > > I know I know most of the world hasn't seen or heard of anything > > > besides x86.. and "64bit" means AMD64... if we just had "LINUX" > and > > > "LINUX64" hardly anyone would see a problem.. > > > > Sorry, small misunderstanding. I didn't want to omit all > architecture/ > > processor information, just leave out the LIBC6. So perhaps > > LINUX_MIPS32 or LINUX_AMD64 etc. would suffice? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Mar 29 04:52:10 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 29 Mar 2009 02:52:10 +0000 Subject: [M3devel] NetBSD2_i386 archives available Message-ID: NetBSD2_i386 min/std archives are now at http://modula3.elegosoft.com/cm3/uploaded-archives/ They have paths to /tmp/random/*.so. You will want to set $LD_LIBRARY_PATH, for example: export LD_LIBRARY_PATH=/cm3/lib or export LD_LIBRARY_PATH=/usr/local/cm3/lib This is fixed, but after I made the archives. (You'll still need to set LD_LIBRARY_PATH.) It'll be nice I think to use "$ORIGIN" on NetBSD 5.0 and wherever else it is supported, and set the paths to $ORIGIN/../lib. That way the install point can be anywhere and at least "installed"/shipped binaries can run without any environment variable. This isn't a new port, but it had been mising in recent releases. I wasn't able to bootstrap from the most recent release, didn't debug that, so did a cross build. This was actually on NetBSD 4.0.1, not "2". I switched it to use pthreads by default and the newer/smaller/more-portable *.i3 files. I did not build or test user threads, but, as with Linux/Darwin/SOL*, I left in the older Usignal.i3 etc. for their support. I did the work in Virtual PC; it was slow. Juno and formsedit startup and display remotely. I didn't have the patience for Juno to finish initializing. I don't know if I deleted all the *.tar.gz files by accident or they were lost or what, but I restored them all from the *.tar.lzma files. - Jay From hendrik at topoi.pooq.com Sun Mar 29 21:10:56 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 29 Mar 2009 15:10:56 -0400 Subject: [M3devel] small objects Message-ID: <20090329191056.GA5664@topoi.pooq.com> There are many times I want to express data which could be efficiently coded as the disjoing union of (small) integer and pointer to object. The pointer-to-object is used in the case where tho objects are big; the (small) integer for the more common case where the objects are small. High-level languages seem to pe quite paranoid about admitting thise kind of data into the fold, except maybe for Lisp systems, which have been doing this from time immemorial. (I believe CAML does this, too). These languages use it internally, and manage to (mostly) hide it from the user. The X toolkit uses this trick too -- there's a constant somewhere, and if an integer is less than this constant, it's passed to an X toolkit function as an integer; otherwise by reference. The idea there is that there's a range of addresses of storage that can never be used as parameters for the X toolkit functions (presumably because of hardware or OS limitations), and that the bit patterns that are unavailable for addresses can be used as small integers. Now the semantics of such a union, efficiently coded, are quite clear. There's a range of numbers that can be packed unamiguously into pointers, and if your integer can be so packed, you do it; otherwise you use a reference to sime kind of INTEGER object elsewhere. There are operations for packing integers and object pointers into such words, and others for unpacking them (complete with type-test). The actual physical representation can be machine- or implemetation dependent -- you could do a bit of shifting and pack integers into words with the low bit set (if pointers to objects are usually aligned in some way, the integers will stand out as being unalinged) Or you could use an uppoer bound on "small" integers, as C does. And on a machine where such packing is impossible (for whatever reason) you could simply set the upper bound of (the absolute alue of) such packable integers to be zero, so there wouldn't be any. Is there any way such a thing can be done in Modula 3? Remember -- I do want the garbage collector to be aware of such conventions and do proper tracing on the pointers? (I suspect the answer is "no". But would be a pity.) -- hendrik From mika at async.caltech.edu Sun Mar 29 21:31:19 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 12:31:19 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Sun, 29 Mar 2009 15:10:56 EDT." <20090329191056.GA5664@topoi.pooq.com> Message-ID: <200903291931.n2TJVJoR045850@camembert.async.caltech.edu> I asked Tony about this and he said that currently it will confuse the GC but that it's a minor change. I wanted it for my proposed Smalltalk-in-M3 environment, which has since morphed to a Scheme-in-M3 environment (much easier to code), and I would still like it :-) (But I have plenty of other issues in my environment also that need my attention more urgently at the moment...) Mika hendrik at topoi.pooq.com writes: >There are many times I want to express data which could be efficiently >coded as the disjoing union of (small) integer and pointer to object. >The pointer-to-object is used in the case where tho objects are big; >the (small) integer for the more common case where the objects are >small. > >High-level languages seem to pe quite paranoid about admitting thise >kind of data into the fold, except maybe for Lisp systems, which have >been doing this from time immemorial. (I believe CAML does this, too). >These languages use it internally, and manage to (mostly) hide it from >the user. > >The X toolkit uses this trick too -- there's a constant somewhere, and >if an integer is less than this constant, it's passed to an X toolkit >function as an integer; otherwise by reference. The idea there is that >there's a range of addresses of storage that can never be used as >parameters for the X toolkit functions (presumably because of hardware >or OS limitations), and that the bit patterns that are unavailable for >addresses can be used as small integers. > >Now the semantics of such a union, efficiently coded, are quite clear. >There's a range of numbers that can be packed unamiguously into >pointers, and if your integer can be so packed, you do it; >otherwise you use a reference to sime kind of INTEGER object >elsewhere. There are operations for packing integers and object >pointers into such words, and others for unpacking them (complete with >type-test). The actual physical representation can be machine- or >implemetation dependent -- you could do a bit of shifting and pack >integers into words with the low bit set (if pointers to objects are usually aligned in some way, the integers will stand out as being >unalinged) Or you could use an uppoer bound on "small" integers, as C >does. And on a machine where such packing is impossible (for whatever >reason) you could simply set the upper bound of (the absolute alue >of) such packable integers to be zero, so there wouldn't be any. > >Is there any way such a thing can be done in Modula 3? Remember -- I do >want the garbage collector to be aware of such conventions and do proper >tracing on the pointers? > >(I suspect the answer is "no". But would be a pity.) > >-- hendrik From mika at async.caltech.edu Sun Mar 29 21:33:47 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 12:33:47 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Sun, 29 Mar 2009 15:10:56 EDT." <20090329191056.GA5664@topoi.pooq.com> Message-ID: <200903291933.n2TJXlxM045919@camembert.async.caltech.edu> You probably mean something like this: http://www.async.caltech.edu/~mika/interp/ Note that this code, as it stands, probably does not work (if we are to trust what the implementor of the garbage collector has said). Mika hendrik at topoi.pooq.com writes: >There are many times I want to express data which could be efficiently >coded as the disjoing union of (small) integer and pointer to object. >The pointer-to-object is used in the case where tho objects are big; >the (small) integer for the more common case where the objects are >small. > >High-level languages seem to pe quite paranoid about admitting thise >kind of data into the fold, except maybe for Lisp systems, which have >been doing this from time immemorial. (I believe CAML does this, too). >These languages use it internally, and manage to (mostly) hide it from >the user. > >The X toolkit uses this trick too -- there's a constant somewhere, and >if an integer is less than this constant, it's passed to an X toolkit >function as an integer; otherwise by reference. The idea there is that >there's a range of addresses of storage that can never be used as >parameters for the X toolkit functions (presumably because of hardware >or OS limitations), and that the bit patterns that are unavailable for >addresses can be used as small integers. > >Now the semantics of such a union, efficiently coded, are quite clear. >There's a range of numbers that can be packed unamiguously into >pointers, and if your integer can be so packed, you do it; >otherwise you use a reference to sime kind of INTEGER object >elsewhere. There are operations for packing integers and object >pointers into such words, and others for unpacking them (complete with >type-test). The actual physical representation can be machine- or >implemetation dependent -- you could do a bit of shifting and pack >integers into words with the low bit set (if pointers to objects are usually aligned in some way, the integers will stand out as being >unalinged) Or you could use an uppoer bound on "small" integers, as C >does. And on a machine where such packing is impossible (for whatever >reason) you could simply set the upper bound of (the absolute alue >of) such packable integers to be zero, so there wouldn't be any. > >Is there any way such a thing can be done in Modula 3? Remember -- I do >want the garbage collector to be aware of such conventions and do proper >tracing on the pointers? > >(I suspect the answer is "no". But would be a pity.) > >-- hendrik From jay.krell at cornell.edu Sun Mar 29 22:19:32 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 29 Mar 2009 20:19:32 +0000 Subject: [M3devel] small objects In-Reply-To: <200903291931.n2TJVJoR045850@camembert.async.caltech.edu> References: Your message of "Sun, 29 Mar 2009 15:10:56 EDT." <20090329191056.GA5664@topoi.pooq.com> <200903291931.n2TJVJoR045850@camembert.async.caltech.edu> Message-ID: Can we say that anything under 64K is invalid? And in RTAllocator, do some gymnastics to make it so? In particular, like: if an allocation from memmap/malloc/sbrk is under 64K: if it is "small", leak it, and try again if it is "large", free it, and try again This does not guarantee forward progress in the large case. So, if it is large...? Free it, allocate something small, if it is under 64K, leak it, and try again. If it is not under 64K, free it, allocate something larger?' This is better, but can still loop forever. I guess sbrk returns always increasing addresses? If you chose 4K instead of 64K, easier/more portable, given that all existing systems have page size>=4K and NULL is invalid, so 0-4K are invalid. - Jay ---------------------------------------- > To: hendrik at topoi.pooq.com > Date: Sun, 29 Mar 2009 12:31:19 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] small objects > > I asked Tony about this and he said that currently it will confuse > the GC but that it's a minor change. > > I wanted it for my proposed Smalltalk-in-M3 environment, which has > since morphed to a Scheme-in-M3 environment (much easier to code), > and I would still like it :-) (But I have plenty of other issues > in my environment also that need my attention more urgently > at the moment...) > > Mika > > hendrik at topoi.pooq.com writes: >>There are many times I want to express data which could be efficiently >>coded as the disjoing union of (small) integer and pointer to object. >>The pointer-to-object is used in the case where tho objects are big; >>the (small) integer for the more common case where the objects are >>small. >> >>High-level languages seem to pe quite paranoid about admitting thise >>kind of data into the fold, except maybe for Lisp systems, which have >>been doing this from time immemorial. (I believe CAML does this, too). >>These languages use it internally, and manage to (mostly) hide it from >>the user. >> >>The X toolkit uses this trick too -- there's a constant somewhere, and >>if an integer is less than this constant, it's passed to an X toolkit >>function as an integer; otherwise by reference. The idea there is that >>there's a range of addresses of storage that can never be used as >>parameters for the X toolkit functions (presumably because of hardware >>or OS limitations), and that the bit patterns that are unavailable for >>addresses can be used as small integers. >> >>Now the semantics of such a union, efficiently coded, are quite clear. >>There's a range of numbers that can be packed unamiguously into >>pointers, and if your integer can be so packed, you do it; >>otherwise you use a reference to sime kind of INTEGER object >>elsewhere. There are operations for packing integers and object >>pointers into such words, and others for unpacking them (complete with >>type-test). The actual physical representation can be machine- or >>implemetation dependent -- you could do a bit of shifting and pack >>integers into words with the low bit set (if pointers to objects are > usually aligned in some way, the integers will stand out as being >>unalinged) Or you could use an uppoer bound on "small" integers, as C >>does. And on a machine where such packing is impossible (for whatever >>reason) you could simply set the upper bound of (the absolute alue >>of) such packable integers to be zero, so there wouldn't be any. >> >>Is there any way such a thing can be done in Modula 3? Remember -- I do >>want the garbage collector to be aware of such conventions and do proper >>tracing on the pointers? >> >>(I suspect the answer is "no". But would be a pity.) >> >>-- hendrik From mika at async.caltech.edu Sun Mar 29 22:23:03 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 13:23:03 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Sun, 29 Mar 2009 20:19:32 -0000." Message-ID: <200903292023.n2TKN310047704@camembert.async.caltech.edu> My code just shifts the word over by one and sets the LSB to 1. Same as in the Blue Book (that's "Smalltalk-80" by Goldberg and Robson). Mika Jay writes: > >Can we say that anything under 64K is invalid? >And in RTAllocator, do some gymnastics to make it so? >In particular, like: > if an allocation from memmap/malloc/sbrk is under 64K: > if it is "small", leak it, and try again > if it is "large", free it, and try again > This does not guarantee forward progress in the large case. > So, if it is large...? > Free it, allocate something small, if it is under 64K, leak it, and try again. > If it is not under 64K, free it, allocate something larger?' > This is better, but can still loop forever. > >I guess sbrk returns always increasing addresses? >If you chose 4K instead of 64K, easier/more portable, given that all existing systems have page size>=4K and NULL is invalid, so 0-4K are invalid. > > - Jay > > >---------------------------------------- >> To: hendrik at topoi.pooq.com >> Date: Sun, 29 Mar 2009 12:31:19 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] small objects >> >> I asked Tony about this and he said that currently it will confuse >> the GC but that it's a minor change. >> >> I wanted it for my proposed Smalltalk-in-M3 environment, which has >> since morphed to a Scheme-in-M3 environment (much easier to code), >> and I would still like it :-) (But I have plenty of other issues >> in my environment also that need my attention more urgently >> at the moment...) >> >> Mika >> >> hendrik at topoi.pooq.com writes: >>>There are many times I want to express data which could be efficiently >>>coded as the disjoing union of (small) integer and pointer to object. >>>The pointer-to-object is used in the case where tho objects are big; >>>the (small) integer for the more common case where the objects are >>>small. >>> >>>High-level languages seem to pe quite paranoid about admitting thise >>>kind of data into the fold, except maybe for Lisp systems, which have >>>been doing this from time immemorial. (I believe CAML does this, too). >>>These languages use it internally, and manage to (mostly) hide it from >>>the user. >>> >>>The X toolkit uses this trick too -- there's a constant somewhere, and >>>if an integer is less than this constant, it's passed to an X toolkit >>>function as an integer; otherwise by reference. The idea there is that >>>there's a range of addresses of storage that can never be used as >>>parameters for the X toolkit functions (presumably because of hardware >>>or OS limitations), and that the bit patterns that are unavailable for >>>addresses can be used as small integers. >>> >>>Now the semantics of such a union, efficiently coded, are quite clear. >>>There's a range of numbers that can be packed unamiguously into >>>pointers, and if your integer can be so packed, you do it; >>>otherwise you use a reference to sime kind of INTEGER object >>>elsewhere. There are operations for packing integers and object >>>pointers into such words, and others for unpacking them (complete with >>>type-test). The actual physical representation can be machine- or >>>implemetation dependent -- you could do a bit of shifting and pack >>>integers into words with the low bit set (if pointers to objects are >> usually aligned in some way, the integers will stand out as being >>>unalinged) Or you could use an uppoer bound on "small" integers, as C >>>does. And on a machine where such packing is impossible (for whatever >>>reason) you could simply set the upper bound of (the absolute alue >>>of) such packable integers to be zero, so there wouldn't be any. >>> >>>Is there any way such a thing can be done in Modula 3? Remember -- I do >>>want the garbage collector to be aware of such conventions and do proper >>>tracing on the pointers? >>> >>>(I suspect the answer is "no". But would be a pity.) >>> >>>-- hendrik From jay.krell at cornell.edu Sun Mar 29 22:25:38 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 29 Mar 2009 20:25:38 +0000 Subject: [M3devel] small objects In-Reply-To: <200903291931.n2TJVJoR045850@camembert.async.caltech.edu> References: Your message of "Sun, 29 Mar 2009 15:10:56 EDT." <20090329191056.GA5664@topoi.pooq.com> <200903291931.n2TJVJoR045850@camembert.async.caltech.edu> Message-ID: You can also depend on heap being somewhat aligned and use the lower bits as "tag" bits. Like, if you need all 30bit integers to be not heap allocated or somesuch. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; hendrik at topoi.pooq.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] small objects > Date: Sun, 29 Mar 2009 20:19:32 +0000 > > > Can we say that anything under 64K is invalid? > And in RTAllocator, do some gymnastics to make it so? > In particular, like: > if an allocation from memmap/malloc/sbrk is under 64K: > if it is "small", leak it, and try again > if it is "large", free it, and try again > This does not guarantee forward progress in the large case. > So, if it is large...? > Free it, allocate something small, if it is under 64K, leak it, and try again. > If it is not under 64K, free it, allocate something larger?' > This is better, but can still loop forever. > > I guess sbrk returns always increasing addresses? > If you chose 4K instead of 64K, easier/more portable, given that all existing systems have page size>=4K and NULL is invalid, so 0-4K are invalid. > > - Jay > > > ---------------------------------------- >> To: hendrik at topoi.pooq.com >> Date: Sun, 29 Mar 2009 12:31:19 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] small objects >> >> I asked Tony about this and he said that currently it will confuse >> the GC but that it's a minor change. >> >> I wanted it for my proposed Smalltalk-in-M3 environment, which has >> since morphed to a Scheme-in-M3 environment (much easier to code), >> and I would still like it :-) (But I have plenty of other issues >> in my environment also that need my attention more urgently >> at the moment...) >> >> Mika >> >> hendrik at topoi.pooq.com writes: >>>There are many times I want to express data which could be efficiently >>>coded as the disjoing union of (small) integer and pointer to object. >>>The pointer-to-object is used in the case where tho objects are big; >>>the (small) integer for the more common case where the objects are >>>small. >>> >>>High-level languages seem to pe quite paranoid about admitting thise >>>kind of data into the fold, except maybe for Lisp systems, which have >>>been doing this from time immemorial. (I believe CAML does this, too). >>>These languages use it internally, and manage to (mostly) hide it from >>>the user. >>> >>>The X toolkit uses this trick too -- there's a constant somewhere, and >>>if an integer is less than this constant, it's passed to an X toolkit >>>function as an integer; otherwise by reference. The idea there is that >>>there's a range of addresses of storage that can never be used as >>>parameters for the X toolkit functions (presumably because of hardware >>>or OS limitations), and that the bit patterns that are unavailable for >>>addresses can be used as small integers. >>> >>>Now the semantics of such a union, efficiently coded, are quite clear. >>>There's a range of numbers that can be packed unamiguously into >>>pointers, and if your integer can be so packed, you do it; >>>otherwise you use a reference to sime kind of INTEGER object >>>elsewhere. There are operations for packing integers and object >>>pointers into such words, and others for unpacking them (complete with >>>type-test). The actual physical representation can be machine- or >>>implemetation dependent -- you could do a bit of shifting and pack >>>integers into words with the low bit set (if pointers to objects are >> usually aligned in some way, the integers will stand out as being >>>unalinged) Or you could use an uppoer bound on "small" integers, as C >>>does. And on a machine where such packing is impossible (for whatever >>>reason) you could simply set the upper bound of (the absolute alue >>>of) such packable integers to be zero, so there wouldn't be any. >>> >>>Is there any way such a thing can be done in Modula 3? Remember -- I do >>>want the garbage collector to be aware of such conventions and do proper >>>tracing on the pointers? >>> >>>(I suspect the answer is "no". But would be a pity.) >>> >>>-- hendrik From hosking at cs.purdue.edu Mon Mar 30 01:34:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Mar 2009 10:34:43 +1100 Subject: [M3devel] small objects In-Reply-To: <20090329191056.GA5664@topoi.pooq.com> References: <20090329191056.GA5664@topoi.pooq.com> Message-ID: <0885F24C-4D78-481E-8B2B-03353AAAEC2C@cs.purdue.edu> If we could accurately type values in the stack/registers at run time then this would not be a problem. Unfortunately, the compiler does not do this, so it is possible for a derived pointer (reference + offset) to be formed in stack/registers that the garbage collector won't be able to distinguish between one of your tagged values and some derived pointer into the middle of an object. If we could assume that the heap never allocates from some known set of addresses then we could safely distinguish the tagged values. On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: > There are many times I want to express data which could be efficiently > coded as the disjoing union of (small) integer and pointer to object. > The pointer-to-object is used in the case where tho objects are big; > the (small) integer for the more common case where the objects are > small. > > High-level languages seem to pe quite paranoid about admitting thise > kind of data into the fold, except maybe for Lisp systems, which have > been doing this from time immemorial. (I believe CAML does this, > too). > These languages use it internally, and manage to (mostly) hide it from > the user. > > The X toolkit uses this trick too -- there's a constant somewhere, and > if an integer is less than this constant, it's passed to an X toolkit > function as an integer; otherwise by reference. The idea there is > that > there's a range of addresses of storage that can never be used as > parameters for the X toolkit functions (presumably because of hardware > or OS limitations), and that the bit patterns that are unavailable for > addresses can be used as small integers. > > Now the semantics of such a union, efficiently coded, are quite clear. > There's a range of numbers that can be packed unamiguously into > pointers, and if your integer can be so packed, you do it; > otherwise you use a reference to sime kind of INTEGER object > elsewhere. There are operations for packing integers and object > pointers into such words, and others for unpacking them (complete with > type-test). The actual physical representation can be machine- or > implemetation dependent -- you could do a bit of shifting and pack > integers into words with the low bit set (if pointers to objects are > usually aligned in some way, the integers will stand out as being > unalinged) Or you could use an uppoer bound on "small" integers, as C > does. And on a machine where such packing is impossible (for whatever > reason) you could simply set the upper bound of (the absolute alue > of) such packable integers to be zero, so there wouldn't be any. > > Is there any way such a thing can be done in Modula 3? Remember -- > I do > want the garbage collector to be aware of such conventions and do > proper > tracing on the pointers? > > (I suspect the answer is "no". But would be a pity.) > > -- hendrik From hosking at cs.purdue.edu Mon Mar 30 01:27:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Mar 2009 10:27:24 +1100 Subject: [M3devel] small objects In-Reply-To: <20090329191056.GA5664@topoi.pooq.com> References: <20090329191056.GA5664@topoi.pooq.com> Message-ID: <332103DB-A166-4516-809C-529BA0317729@cs.purdue.edu> If we could accurately type values in the stack/registers at run time then this would not be a problem. Unfortunately, the compiler does not do this, so it is possible for a derived pointer (reference + offset) to be formed in stack/registers that the garbage collector won't be able to distinguish between one of your tagged values and some derived pointer into the middle of an object. If we could assume that the heap never allocates from some known set of addresses then we could safely distinguish the tagged values. On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: > There are many times I want to express data which could be efficiently > coded as the disjoing union of (small) integer and pointer to object. > The pointer-to-object is used in the case where tho objects are big; > the (small) integer for the more common case where the objects are > small. > > High-level languages seem to pe quite paranoid about admitting thise > kind of data into the fold, except maybe for Lisp systems, which have > been doing this from time immemorial. (I believe CAML does this, > too). > These languages use it internally, and manage to (mostly) hide it from > the user. > > The X toolkit uses this trick too -- there's a constant somewhere, and > if an integer is less than this constant, it's passed to an X toolkit > function as an integer; otherwise by reference. The idea there is > that > there's a range of addresses of storage that can never be used as > parameters for the X toolkit functions (presumably because of hardware > or OS limitations), and that the bit patterns that are unavailable for > addresses can be used as small integers. > > Now the semantics of such a union, efficiently coded, are quite clear. > There's a range of numbers that can be packed unamiguously into > pointers, and if your integer can be so packed, you do it; > otherwise you use a reference to sime kind of INTEGER object > elsewhere. There are operations for packing integers and object > pointers into such words, and others for unpacking them (complete with > type-test). The actual physical representation can be machine- or > implemetation dependent -- you could do a bit of shifting and pack > integers into words with the low bit set (if pointers to objects are > usually aligned in some way, the integers will stand out as being > unalinged) Or you could use an uppoer bound on "small" integers, as C > does. And on a machine where such packing is impossible (for whatever > reason) you could simply set the upper bound of (the absolute alue > of) such packable integers to be zero, so there wouldn't be any. > > Is there any way such a thing can be done in Modula 3? Remember -- > I do > want the garbage collector to be aware of such conventions and do > proper > tracing on the pointers? > > (I suspect the answer is "no". But would be a pity.) > > -- hendrik From hosking at cs.purdue.edu Mon Mar 30 01:13:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Mar 2009 10:13:43 +1100 Subject: [M3devel] small objects In-Reply-To: References: Your message of "Sun, 29 Mar 2009 15:10:56 EDT." <20090329191056.GA5664@topoi.pooq.com> <200903291931.n2TJVJoR045850@camembert.async.caltech.edu> Message-ID: <3E9AE7FF-BEFC-4E0E-98B5-4F1768F87764@cs.purdue.edu> No good if the tag bits are the same as unaligned pointers from the stack/registers -- we'd end up conservatively pinning pages that just happened to have addresses that coincide with the tagged values. On 30 Mar 2009, at 07:25, Jay wrote: > > You can also depend on heap being somewhat aligned and use the lower > bits as "tag" bits. Like, if you need all 30bit integers to be not > heap allocated or somesuch. > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: mika at async.caltech.edu; hendrik at topoi.pooq.com >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] small objects >> Date: Sun, 29 Mar 2009 20:19:32 +0000 >> >> >> Can we say that anything under 64K is invalid? >> And in RTAllocator, do some gymnastics to make it so? >> In particular, like: >> if an allocation from memmap/malloc/sbrk is under 64K: >> if it is "small", leak it, and try again >> if it is "large", free it, and try again >> This does not guarantee forward progress in the large case. >> So, if it is large...? >> Free it, allocate something small, if it is under 64K, leak it, and >> try again. >> If it is not under 64K, free it, allocate something larger?' >> This is better, but can still loop forever. >> >> I guess sbrk returns always increasing addresses? >> If you chose 4K instead of 64K, easier/more portable, given that >> all existing systems have page size>=4K and NULL is invalid, so >> 0-4K are invalid. >> >> - Jay >> >> >> ---------------------------------------- >>> To: hendrik at topoi.pooq.com >>> Date: Sun, 29 Mar 2009 12:31:19 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] small objects >>> >>> I asked Tony about this and he said that currently it will confuse >>> the GC but that it's a minor change. >>> >>> I wanted it for my proposed Smalltalk-in-M3 environment, which has >>> since morphed to a Scheme-in-M3 environment (much easier to code), >>> and I would still like it :-) (But I have plenty of other issues >>> in my environment also that need my attention more urgently >>> at the moment...) >>> >>> Mika >>> >>> hendrik at topoi.pooq.com writes: >>>> There are many times I want to express data which could be >>>> efficiently >>>> coded as the disjoing union of (small) integer and pointer to >>>> object. >>>> The pointer-to-object is used in the case where tho objects are >>>> big; >>>> the (small) integer for the more common case where the objects are >>>> small. >>>> >>>> High-level languages seem to pe quite paranoid about admitting >>>> thise >>>> kind of data into the fold, except maybe for Lisp systems, which >>>> have >>>> been doing this from time immemorial. (I believe CAML does this, >>>> too). >>>> These languages use it internally, and manage to (mostly) hide it >>>> from >>>> the user. >>>> >>>> The X toolkit uses this trick too -- there's a constant >>>> somewhere, and >>>> if an integer is less than this constant, it's passed to an X >>>> toolkit >>>> function as an integer; otherwise by reference. The idea there is >>>> that >>>> there's a range of addresses of storage that can never be used as >>>> parameters for the X toolkit functions (presumably because of >>>> hardware >>>> or OS limitations), and that the bit patterns that are >>>> unavailable for >>>> addresses can be used as small integers. >>>> >>>> Now the semantics of such a union, efficiently coded, are quite >>>> clear. >>>> There's a range of numbers that can be packed unamiguously into >>>> pointers, and if your integer can be so packed, you do it; >>>> otherwise you use a reference to sime kind of INTEGER object >>>> elsewhere. There are operations for packing integers and object >>>> pointers into such words, and others for unpacking them (complete >>>> with >>>> type-test). The actual physical representation can be machine- or >>>> implemetation dependent -- you could do a bit of shifting and pack >>>> integers into words with the low bit set (if pointers to objects >>>> are >>> usually aligned in some way, the integers will stand out as being >>>> unalinged) Or you could use an uppoer bound on "small" integers, >>>> as C >>>> does. And on a machine where such packing is impossible (for >>>> whatever >>>> reason) you could simply set the upper bound of (the absolute alue >>>> of) such packable integers to be zero, so there wouldn't be any. >>>> >>>> Is there any way such a thing can be done in Modula 3? Remember >>>> -- I do >>>> want the garbage collector to be aware of such conventions and do >>>> proper >>>> tracing on the pointers? >>>> >>>> (I suspect the answer is "no". But would be a pity.) >>>> >>>> -- hendrik From mika at async.caltech.edu Mon Mar 30 01:49:14 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 16:49:14 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 30 Mar 2009 10:34:43 +1100." <0885F24C-4D78-481E-8B2B-03353AAAEC2C@cs.purdue.edu> Message-ID: <200903292349.n2TNnEPv054525@camembert.async.caltech.edu> Tony, Doesn't this already happen with INTEGER, REAL, LONGREAL, etc., objects? Mika Tony Hosking writes: >If we could accurately type values in the stack/registers at run time >then this would not be a problem. Unfortunately, the compiler does >not do this, so it is possible for a derived pointer (reference + >offset) to be formed in stack/registers that the garbage collector >won't be able to distinguish between one of your tagged values and >some derived pointer into the middle of an object. If we could assume >that the heap never allocates from some known set of addresses then we >could safely distinguish the tagged values. > >On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: > >> There are many times I want to express data which could be efficiently >> coded as the disjoing union of (small) integer and pointer to object. >> The pointer-to-object is used in the case where tho objects are big; >> the (small) integer for the more common case where the objects are >> small. >> >> High-level languages seem to pe quite paranoid about admitting thise >> kind of data into the fold, except maybe for Lisp systems, which have >> been doing this from time immemorial. (I believe CAML does this, >> too). >> These languages use it internally, and manage to (mostly) hide it from >> the user. >> >> The X toolkit uses this trick too -- there's a constant somewhere, and >> if an integer is less than this constant, it's passed to an X toolkit >> function as an integer; otherwise by reference. The idea there is >> that >> there's a range of addresses of storage that can never be used as >> parameters for the X toolkit functions (presumably because of hardware >> or OS limitations), and that the bit patterns that are unavailable for >> addresses can be used as small integers. >> >> Now the semantics of such a union, efficiently coded, are quite clear. >> There's a range of numbers that can be packed unamiguously into >> pointers, and if your integer can be so packed, you do it; >> otherwise you use a reference to sime kind of INTEGER object >> elsewhere. There are operations for packing integers and object >> pointers into such words, and others for unpacking them (complete with >> type-test). The actual physical representation can be machine- or >> implemetation dependent -- you could do a bit of shifting and pack >> integers into words with the low bit set (if pointers to objects are >> usually aligned in some way, the integers will stand out as being >> unalinged) Or you could use an uppoer bound on "small" integers, as C >> does. And on a machine where such packing is impossible (for whatever >> reason) you could simply set the upper bound of (the absolute alue >> of) such packable integers to be zero, so there wouldn't be any. >> >> Is there any way such a thing can be done in Modula 3? Remember -- >> I do >> want the garbage collector to be aware of such conventions and do >> proper >> tracing on the pointers? >> >> (I suspect the answer is "no". But would be a pity.) >> >> -- hendrik From hosking at cs.purdue.edu Mon Mar 30 03:12:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Mar 2009 12:12:12 +1100 Subject: [M3devel] small objects In-Reply-To: <200903292349.n2TNnEPv054525@camembert.async.caltech.edu> References: <200903292349.n2TNnEPv054525@camembert.async.caltech.edu> Message-ID: Sorry, yes, I am not awake yet this morning. Need more coffeee. Of course this occurs even for all untagged values. The main problem is that it would be dangerous generally to allow reference fields to contain tagged values, since then even safe code could try to dereference what would amount to actually being a tagged value non-reference. What we really need is a new type "tagged reference" distinct from normal references with associated API to extract the reference/value it holds. The compiler would need to generate heap maps that include these for processing by the collector, just as it does for ordinary references. On 30 Mar 2009, at 10:49, Mika Nystrom wrote: > Tony, > > Doesn't this already happen with INTEGER, REAL, LONGREAL, etc., > objects? > > Mika > > Tony Hosking writes: >> If we could accurately type values in the stack/registers at run time >> then this would not be a problem. Unfortunately, the compiler does >> not do this, so it is possible for a derived pointer (reference + >> offset) to be formed in stack/registers that the garbage collector >> won't be able to distinguish between one of your tagged values and >> some derived pointer into the middle of an object. If we could >> assume >> that the heap never allocates from some known set of addresses then >> we >> could safely distinguish the tagged values. >> >> On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: >> >>> There are many times I want to express data which could be >>> efficiently >>> coded as the disjoing union of (small) integer and pointer to >>> object. >>> The pointer-to-object is used in the case where tho objects are big; >>> the (small) integer for the more common case where the objects are >>> small. >>> >>> High-level languages seem to pe quite paranoid about admitting thise >>> kind of data into the fold, except maybe for Lisp systems, which >>> have >>> been doing this from time immemorial. (I believe CAML does this, >>> too). >>> These languages use it internally, and manage to (mostly) hide it >>> from >>> the user. >>> >>> The X toolkit uses this trick too -- there's a constant somewhere, >>> and >>> if an integer is less than this constant, it's passed to an X >>> toolkit >>> function as an integer; otherwise by reference. The idea there is >>> that >>> there's a range of addresses of storage that can never be used as >>> parameters for the X toolkit functions (presumably because of >>> hardware >>> or OS limitations), and that the bit patterns that are unavailable >>> for >>> addresses can be used as small integers. >>> >>> Now the semantics of such a union, efficiently coded, are quite >>> clear. >>> There's a range of numbers that can be packed unamiguously into >>> pointers, and if your integer can be so packed, you do it; >>> otherwise you use a reference to sime kind of INTEGER object >>> elsewhere. There are operations for packing integers and object >>> pointers into such words, and others for unpacking them (complete >>> with >>> type-test). The actual physical representation can be machine- or >>> implemetation dependent -- you could do a bit of shifting and pack >>> integers into words with the low bit set (if pointers to objects are >>> usually aligned in some way, the integers will stand out as being >>> unalinged) Or you could use an uppoer bound on "small" integers, >>> as C >>> does. And on a machine where such packing is impossible (for >>> whatever >>> reason) you could simply set the upper bound of (the absolute alue >>> of) such packable integers to be zero, so there wouldn't be any. >>> >>> Is there any way such a thing can be done in Modula 3? Remember -- >>> I do >>> want the garbage collector to be aware of such conventions and do >>> proper >>> tracing on the pointers? >>> >>> (I suspect the answer is "no". But would be a pity.) >>> >>> -- hendrik From mika at async.caltech.edu Mon Mar 30 03:48:56 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 18:48:56 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 30 Mar 2009 12:12:12 +1100." Message-ID: <200903300148.n2U1mu1d058648@camembert.async.caltech.edu> Hmmmmm... in my UNSAFE INTERFACE I declare my special type as REFANY (see the URL I sent a few messages ago). Since you can't deref REFANY, I'm thinking that... it's mainly a problem with TYPECASE, TYPECODE, and ISTYPE...? (In safe code, that is.) Also the GC would have to know that refs that are # 0 (mod 4) aren't real references and not try to follow those. As long as they are on the stack or in registers there's not much you can do... I don't think this is all that difficult. My example code has a very simple API of the kind you describe. See SmallInteger.[im]3... Mika Tony Hosking writes: >Sorry, yes, I am not awake yet this morning. Need more coffeee. Of >course this occurs even for all untagged values. > >The main problem is that it would be dangerous generally to allow >reference fields to contain tagged values, since then even safe code >could try to dereference what would amount to actually being a tagged >value non-reference. What we really need is a new type "tagged >reference" distinct from normal references with associated API to >extract the reference/value it holds. The compiler would need to >generate heap maps that include these for processing by the collector, >just as it does for ordinary references. > >On 30 Mar 2009, at 10:49, Mika Nystrom wrote: > >> Tony, >> >> Doesn't this already happen with INTEGER, REAL, LONGREAL, etc., >> objects? >> >> Mika >> >> Tony Hosking writes: >>> If we could accurately type values in the stack/registers at run time >>> then this would not be a problem. Unfortunately, the compiler does >>> not do this, so it is possible for a derived pointer (reference + >>> offset) to be formed in stack/registers that the garbage collector >>> won't be able to distinguish between one of your tagged values and >>> some derived pointer into the middle of an object. If we could >>> assume >>> that the heap never allocates from some known set of addresses then >>> we >>> could safely distinguish the tagged values. >>> >>> On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: >>> >>>> There are many times I want to express data which could be >>>> efficiently >>>> coded as the disjoing union of (small) integer and pointer to >>>> object. >>>> The pointer-to-object is used in the case where tho objects are big; >>>> the (small) integer for the more common case where the objects are >>>> small. >>>> >>>> High-level languages seem to pe quite paranoid about admitting thise >>>> kind of data into the fold, except maybe for Lisp systems, which >>>> have >>>> been doing this from time immemorial. (I believe CAML does this, >>>> too). >>>> These languages use it internally, and manage to (mostly) hide it >>>> from >>>> the user. >>>> >>>> The X toolkit uses this trick too -- there's a constant somewhere, >>>> and >>>> if an integer is less than this constant, it's passed to an X >>>> toolkit >>>> function as an integer; otherwise by reference. The idea there is >>>> that >>>> there's a range of addresses of storage that can never be used as >>>> parameters for the X toolkit functions (presumably because of >>>> hardware >>>> or OS limitations), and that the bit patterns that are unavailable >>>> for >>>> addresses can be used as small integers. >>>> >>>> Now the semantics of such a union, efficiently coded, are quite >>>> clear. >>>> There's a range of numbers that can be packed unamiguously into >>>> pointers, and if your integer can be so packed, you do it; >>>> otherwise you use a reference to sime kind of INTEGER object >>>> elsewhere. There are operations for packing integers and object >>>> pointers into such words, and others for unpacking them (complete >>>> with >>>> type-test). The actual physical representation can be machine- or >>>> implemetation dependent -- you could do a bit of shifting and pack >>>> integers into words with the low bit set (if pointers to objects are >>>> usually aligned in some way, the integers will stand out as being >>>> unalinged) Or you could use an uppoer bound on "small" integers, >>>> as C >>>> does. And on a machine where such packing is impossible (for >>>> whatever >>>> reason) you could simply set the upper bound of (the absolute alue >>>> of) such packable integers to be zero, so there wouldn't be any. >>>> >>>> Is there any way such a thing can be done in Modula 3? Remember -- >>>> I do >>>> want the garbage collector to be aware of such conventions and do >>>> proper >>>> tracing on the pointers? >>>> >>>> (I suspect the answer is "no". But would be a pity.) >>>> >>>> -- hendrik > From mika at async.caltech.edu Mon Mar 30 04:06:01 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 19:06:01 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Sun, 29 Mar 2009 18:48:56 PDT." <200903300148.n2U1mu1d058648@camembert.async.caltech.edu> Message-ID: <200903300206.n2U261i4059318@camembert.async.caltech.edu> Mika Nystrom writes: >Also the GC would have to know that refs <> that are # 0 (mod 4) aren't >real references and not try to follow those. Insert, in place of <> ... that it encounters on the heap and ... From hosking at cs.purdue.edu Mon Mar 30 04:33:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Mar 2009 13:33:37 +1100 Subject: [M3devel] small objects In-Reply-To: <200903300148.n2U1mu1d058648@camembert.async.caltech.edu> References: <200903300148.n2U1mu1d058648@camembert.async.caltech.edu> Message-ID: Yes, I've just been thinking about this and trying to come up with a proposal, somewhat along the lines you describe. My real concern is that you don't want any of the reference operations (including down- casts) to apply to the tagged value type. But you do want the collector to be aware of it. We'd need a new builtin type like TAGGED or something and operations for extracting the values. A slightly wacky alternative might allow NULL to have values other than NIL. Doing this would require smartening up the compiler and run- time to allow for non-NIL NULL values. This would let a REFANY hold any number of different NULL values. Unfortunately, the representation of NIL as 0 and other NULL values using a tag bit doesn't make for an easy catch-all test for NULL. On 30 Mar 2009, at 12:48, Mika Nystrom wrote: > Hmmmmm... in my UNSAFE INTERFACE I declare my special type as > REFANY (see the URL I sent a few messages ago). > > Since you can't deref REFANY, I'm thinking that... it's mainly a > problem with TYPECASE, TYPECODE, and ISTYPE...? (In safe code, > that is.) > > Also the GC would have to know that refs that are # 0 (mod 4) aren't > real references and not try to follow those. As long as they are > on the stack or in registers there's not much you can do... > > I don't think this is all that difficult. My example code has a very > simple API of the kind you describe. See SmallInteger.[im]3... > > Mika > > Tony Hosking writes: >> Sorry, yes, I am not awake yet this morning. Need more coffeee. Of >> course this occurs even for all untagged values. >> >> The main problem is that it would be dangerous generally to allow >> reference fields to contain tagged values, since then even safe code >> could try to dereference what would amount to actually being a tagged >> value non-reference. What we really need is a new type "tagged >> reference" distinct from normal references with associated API to >> extract the reference/value it holds. The compiler would need to >> generate heap maps that include these for processing by the >> collector, >> just as it does for ordinary references. >> >> On 30 Mar 2009, at 10:49, Mika Nystrom wrote: >> >>> Tony, >>> >>> Doesn't this already happen with INTEGER, REAL, LONGREAL, etc., >>> objects? >>> >>> Mika >>> >>> Tony Hosking writes: >>>> If we could accurately type values in the stack/registers at run >>>> time >>>> then this would not be a problem. Unfortunately, the compiler does >>>> not do this, so it is possible for a derived pointer (reference + >>>> offset) to be formed in stack/registers that the garbage collector >>>> won't be able to distinguish between one of your tagged values and >>>> some derived pointer into the middle of an object. If we could >>>> assume >>>> that the heap never allocates from some known set of addresses then >>>> we >>>> could safely distinguish the tagged values. >>>> >>>> On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: >>>> >>>>> There are many times I want to express data which could be >>>>> efficiently >>>>> coded as the disjoing union of (small) integer and pointer to >>>>> object. >>>>> The pointer-to-object is used in the case where tho objects are >>>>> big; >>>>> the (small) integer for the more common case where the objects are >>>>> small. >>>>> >>>>> High-level languages seem to pe quite paranoid about admitting >>>>> thise >>>>> kind of data into the fold, except maybe for Lisp systems, which >>>>> have >>>>> been doing this from time immemorial. (I believe CAML does this, >>>>> too). >>>>> These languages use it internally, and manage to (mostly) hide it >>>>> from >>>>> the user. >>>>> >>>>> The X toolkit uses this trick too -- there's a constant somewhere, >>>>> and >>>>> if an integer is less than this constant, it's passed to an X >>>>> toolkit >>>>> function as an integer; otherwise by reference. The idea there is >>>>> that >>>>> there's a range of addresses of storage that can never be used as >>>>> parameters for the X toolkit functions (presumably because of >>>>> hardware >>>>> or OS limitations), and that the bit patterns that are unavailable >>>>> for >>>>> addresses can be used as small integers. >>>>> >>>>> Now the semantics of such a union, efficiently coded, are quite >>>>> clear. >>>>> There's a range of numbers that can be packed unamiguously into >>>>> pointers, and if your integer can be so packed, you do it; >>>>> otherwise you use a reference to sime kind of INTEGER object >>>>> elsewhere. There are operations for packing integers and object >>>>> pointers into such words, and others for unpacking them (complete >>>>> with >>>>> type-test). The actual physical representation can be machine- or >>>>> implemetation dependent -- you could do a bit of shifting and pack >>>>> integers into words with the low bit set (if pointers to objects >>>>> are >>>>> usually aligned in some way, the integers will stand out as being >>>>> unalinged) Or you could use an uppoer bound on "small" integers, >>>>> as C >>>>> does. And on a machine where such packing is impossible (for >>>>> whatever >>>>> reason) you could simply set the upper bound of (the absolute alue >>>>> of) such packable integers to be zero, so there wouldn't be any. >>>>> >>>>> Is there any way such a thing can be done in Modula 3? Remember >>>>> -- >>>>> I do >>>>> want the garbage collector to be aware of such conventions and do >>>>> proper >>>>> tracing on the pointers? >>>>> >>>>> (I suspect the answer is "no". But would be a pity.) >>>>> >>>>> -- hendrik >> From martinbishop at bellsouth.net Mon Mar 30 04:44:41 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Sun, 29 Mar 2009 21:44:41 -0500 Subject: [M3devel] small objects In-Reply-To: <200903300206.n2U261i4059318@camembert.async.caltech.edu> References: <200903300206.n2U261i4059318@camembert.async.caltech.edu> Message-ID: <49D03219.9000209@bellsouth.net> Insert what? Mika Nystrom wrote: > Mika Nystrom writes: >> Also the GC would have to know that refs <> that are # 0 (mod 4) aren't >> real references and not try to follow those. > > Insert, in place of <> > > ... that it encounters on the heap and ... > From mika at async.caltech.edu Mon Mar 30 05:33:11 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 20:33:11 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 30 Mar 2009 13:33:37 +1100." Message-ID: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> Ah you are thinking of doing it properly. I was thinking.. "hack". Make TYPECASE, TYPECODE, ISTYPE, and NARROW abort if a REFANY holds a TaggedThing.T Make TaggedThing.IsT test if it is a TaggedThing.T TaggedThing.ToInt TaggedThing.T -> [-Min .. Max] TaggedThing.FromInt [-Min .. Max] -> TaggedThing.T REVEAL only TaggedThing.T <: REFANY I think that accomplishes everything. No? In a non-UNSAFE environment, you can't dereference it or (successfully) cast it to anything unless you have a revelation of more than REFANY, anyhow. If I understand your idea correctly, I think it really only involves adding an ISTYPE(x,TAGGED) case. There's no TYPECODE and there might be some extra complication in adding it to TYPECASE since it's not a REF... Since you might as well handle ISTYPE(x,TAGGED) with TaggedThing.IsT, do you really need anything more than I propose? (I.e., no changes to the language, just a new library interface.) Actually maybe I do mean for it to be = REFANY, not <:. Then you can't NARROW it to anything other than REFANY anyhow. ISTYPE needn't actually abort, it could just return FALSE for all cases except REFANY. Leaves only Pickles, ... or am I missing something? Mika Tony Hosking writes: >Yes, I've just been thinking about this and trying to come up with a >proposal, somewhat along the lines you describe. My real concern is >that you don't want any of the reference operations (including down- >casts) to apply to the tagged value type. But you do want the >collector to be aware of it. We'd need a new builtin type like TAGGED >or something and operations for extracting the values. > >A slightly wacky alternative might allow NULL to have values other >than NIL. Doing this would require smartening up the compiler and run- >time to allow for non-NIL NULL values. This would let a REFANY hold >any number of different NULL values. Unfortunately, the >representation of NIL as 0 and other NULL values using a tag bit >doesn't make for an easy catch-all test for NULL. > >On 30 Mar 2009, at 12:48, Mika Nystrom wrote: > >> Hmmmmm... in my UNSAFE INTERFACE I declare my special type as >> REFANY (see the URL I sent a few messages ago). >> >> Since you can't deref REFANY, I'm thinking that... it's mainly a >> problem with TYPECASE, TYPECODE, and ISTYPE...? (In safe code, >> that is.) >> >> Also the GC would have to know that refs that are # 0 (mod 4) aren't >> real references and not try to follow those. As long as they are >> on the stack or in registers there's not much you can do... >> >> I don't think this is all that difficult. My example code has a very >> simple API of the kind you describe. See SmallInteger.[im]3... >> >> Mika >> >> Tony Hosking writes: >>> Sorry, yes, I am not awake yet this morning. Need more coffeee. Of >>> course this occurs even for all untagged values. >>> >>> The main problem is that it would be dangerous generally to allow >>> reference fields to contain tagged values, since then even safe code >>> could try to dereference what would amount to actually being a tagged >>> value non-reference. What we really need is a new type "tagged >>> reference" distinct from normal references with associated API to >>> extract the reference/value it holds. The compiler would need to >>> generate heap maps that include these for processing by the >>> collector, >>> just as it does for ordinary references. >>> >>> On 30 Mar 2009, at 10:49, Mika Nystrom wrote: >>> >>>> Tony, >>>> >>>> Doesn't this already happen with INTEGER, REAL, LONGREAL, etc., >>>> objects? >>>> >>>> Mika >>>> >>>> Tony Hosking writes: >>>>> If we could accurately type values in the stack/registers at run >>>>> time >>>>> then this would not be a problem. Unfortunately, the compiler does >>>>> not do this, so it is possible for a derived pointer (reference + >>>>> offset) to be formed in stack/registers that the garbage collector >>>>> won't be able to distinguish between one of your tagged values and >>>>> some derived pointer into the middle of an object. If we could >>>>> assume >>>>> that the heap never allocates from some known set of addresses then >>>>> we >>>>> could safely distinguish the tagged values. >>>>> >>>>> On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: >>>>> >>>>>> There are many times I want to express data which could be >>>>>> efficiently >>>>>> coded as the disjoing union of (small) integer and pointer to >>>>>> object. >>>>>> The pointer-to-object is used in the case where tho objects are >>>>>> big; >>>>>> the (small) integer for the more common case where the objects are >>>>>> small. >>>>>> >>>>>> High-level languages seem to pe quite paranoid about admitting >>>>>> thise >>>>>> kind of data into the fold, except maybe for Lisp systems, which >>>>>> have >>>>>> been doing this from time immemorial. (I believe CAML does this, >>>>>> too). >>>>>> These languages use it internally, and manage to (mostly) hide it >>>>>> from >>>>>> the user. >>>>>> >>>>>> The X toolkit uses this trick too -- there's a constant somewhere, >>>>>> and >>>>>> if an integer is less than this constant, it's passed to an X >>>>>> toolkit >>>>>> function as an integer; otherwise by reference. The idea there is >>>>>> that >>>>>> there's a range of addresses of storage that can never be used as >>>>>> parameters for the X toolkit functions (presumably because of >>>>>> hardware >>>>>> or OS limitations), and that the bit patterns that are unavailable >>>>>> for >>>>>> addresses can be used as small integers. >>>>>> >>>>>> Now the semantics of such a union, efficiently coded, are quite >>>>>> clear. >>>>>> There's a range of numbers that can be packed unamiguously into >>>>>> pointers, and if your integer can be so packed, you do it; >>>>>> otherwise you use a reference to sime kind of INTEGER object >>>>>> elsewhere. There are operations for packing integers and object >>>>>> pointers into such words, and others for unpacking them (complete >>>>>> with >>>>>> type-test). The actual physical representation can be machine- or >>>>>> implemetation dependent -- you could do a bit of shifting and pack >>>>>> integers into words with the low bit set (if pointers to objects >>>>>> are >>>>>> usually aligned in some way, the integers will stand out as being >>>>>> unalinged) Or you could use an uppoer bound on "small" integers, >>>>>> as C >>>>>> does. And on a machine where such packing is impossible (for >>>>>> whatever >>>>>> reason) you could simply set the upper bound of (the absolute alue >>>>>> of) such packable integers to be zero, so there wouldn't be any. >>>>>> >>>>>> Is there any way such a thing can be done in Modula 3? Remember >>>>>> -- >>>>>> I do >>>>>> want the garbage collector to be aware of such conventions and do >>>>>> proper >>>>>> tracing on the pointers? >>>>>> >>>>>> (I suspect the answer is "no". But would be a pity.) >>>>>> >>>>>> -- hendrik >>> > From hosking at cs.purdue.edu Mon Mar 30 07:47:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Mar 2009 16:47:57 +1100 Subject: [M3devel] small objects In-Reply-To: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> Message-ID: It is a much more pervasive hack than I would be comfortable with since it touches on the compiler (for all the type operations) as well as the run-time system in ways that are pretty gross. I would much rather have a new TAGGED builtin. ISTYPE would not work on it since that only works on references. The only thing you need is a way to extract the value -- we could overload VAL(x, T) where x can be a TAGGED and T can be REFANY or INTEGER. On 30 Mar 2009, at 14:33, Mika Nystrom wrote: > Ah you are thinking of doing it properly. > > I was thinking.. "hack". Make TYPECASE, TYPECODE, ISTYPE, and NARROW > abort if a REFANY holds a TaggedThing.T > > Make TaggedThing.IsT test if it is a TaggedThing.T > > TaggedThing.ToInt TaggedThing.T -> [-Min .. Max] > > TaggedThing.FromInt [-Min .. Max] -> TaggedThing.T > > REVEAL only TaggedThing.T <: REFANY > > I think that accomplishes everything. No? In a non-UNSAFE > environment, you can't dereference it or (successfully) cast it to > anything unless you have a revelation of more than REFANY, anyhow. > > If I understand your idea correctly, I think it really only involves > adding an ISTYPE(x,TAGGED) case. There's no TYPECODE and there might > be some extra complication in adding it to TYPECASE since it's not > a REF... > > Since you might as well handle ISTYPE(x,TAGGED) with TaggedThing.IsT, > do you really need anything more than I propose? (I.e., no changes > to the language, just a new library interface.) > > Actually maybe I do mean for it to be = REFANY, not <:. Then you > can't NARROW it to anything other than REFANY anyhow. > > ISTYPE needn't actually abort, it could just return FALSE for > all cases except REFANY. > > Leaves only Pickles, ... or am I missing something? > > Mika > > Tony Hosking writes: >> Yes, I've just been thinking about this and trying to come up with a >> proposal, somewhat along the lines you describe. My real concern is >> that you don't want any of the reference operations (including down- >> casts) to apply to the tagged value type. But you do want the >> collector to be aware of it. We'd need a new builtin type like >> TAGGED >> or something and operations for extracting the values. >> >> A slightly wacky alternative might allow NULL to have values other >> than NIL. Doing this would require smartening up the compiler and >> run- >> time to allow for non-NIL NULL values. This would let a REFANY hold >> any number of different NULL values. Unfortunately, the >> representation of NIL as 0 and other NULL values using a tag bit >> doesn't make for an easy catch-all test for NULL. >> >> On 30 Mar 2009, at 12:48, Mika Nystrom wrote: >> >>> Hmmmmm... in my UNSAFE INTERFACE I declare my special type as >>> REFANY (see the URL I sent a few messages ago). >>> >>> Since you can't deref REFANY, I'm thinking that... it's mainly a >>> problem with TYPECASE, TYPECODE, and ISTYPE...? (In safe code, >>> that is.) >>> >>> Also the GC would have to know that refs that are # 0 (mod 4) aren't >>> real references and not try to follow those. As long as they are >>> on the stack or in registers there's not much you can do... >>> >>> I don't think this is all that difficult. My example code has a >>> very >>> simple API of the kind you describe. See SmallInteger.[im]3... >>> >>> Mika >>> >>> Tony Hosking writes: >>>> Sorry, yes, I am not awake yet this morning. Need more coffeee. Of >>>> course this occurs even for all untagged values. >>>> >>>> The main problem is that it would be dangerous generally to allow >>>> reference fields to contain tagged values, since then even safe >>>> code >>>> could try to dereference what would amount to actually being a >>>> tagged >>>> value non-reference. What we really need is a new type "tagged >>>> reference" distinct from normal references with associated API to >>>> extract the reference/value it holds. The compiler would need to >>>> generate heap maps that include these for processing by the >>>> collector, >>>> just as it does for ordinary references. >>>> >>>> On 30 Mar 2009, at 10:49, Mika Nystrom wrote: >>>> >>>>> Tony, >>>>> >>>>> Doesn't this already happen with INTEGER, REAL, LONGREAL, etc., >>>>> objects? >>>>> >>>>> Mika >>>>> >>>>> Tony Hosking writes: >>>>>> If we could accurately type values in the stack/registers at run >>>>>> time >>>>>> then this would not be a problem. Unfortunately, the compiler >>>>>> does >>>>>> not do this, so it is possible for a derived pointer (reference + >>>>>> offset) to be formed in stack/registers that the garbage >>>>>> collector >>>>>> won't be able to distinguish between one of your tagged values >>>>>> and >>>>>> some derived pointer into the middle of an object. If we could >>>>>> assume >>>>>> that the heap never allocates from some known set of addresses >>>>>> then >>>>>> we >>>>>> could safely distinguish the tagged values. >>>>>> >>>>>> On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: >>>>>> >>>>>>> There are many times I want to express data which could be >>>>>>> efficiently >>>>>>> coded as the disjoing union of (small) integer and pointer to >>>>>>> object. >>>>>>> The pointer-to-object is used in the case where tho objects are >>>>>>> big; >>>>>>> the (small) integer for the more common case where the objects >>>>>>> are >>>>>>> small. >>>>>>> >>>>>>> High-level languages seem to pe quite paranoid about admitting >>>>>>> thise >>>>>>> kind of data into the fold, except maybe for Lisp systems, which >>>>>>> have >>>>>>> been doing this from time immemorial. (I believe CAML does >>>>>>> this, >>>>>>> too). >>>>>>> These languages use it internally, and manage to (mostly) hide >>>>>>> it >>>>>>> from >>>>>>> the user. >>>>>>> >>>>>>> The X toolkit uses this trick too -- there's a constant >>>>>>> somewhere, >>>>>>> and >>>>>>> if an integer is less than this constant, it's passed to an X >>>>>>> toolkit >>>>>>> function as an integer; otherwise by reference. The idea >>>>>>> there is >>>>>>> that >>>>>>> there's a range of addresses of storage that can never be used >>>>>>> as >>>>>>> parameters for the X toolkit functions (presumably because of >>>>>>> hardware >>>>>>> or OS limitations), and that the bit patterns that are >>>>>>> unavailable >>>>>>> for >>>>>>> addresses can be used as small integers. >>>>>>> >>>>>>> Now the semantics of such a union, efficiently coded, are quite >>>>>>> clear. >>>>>>> There's a range of numbers that can be packed unamiguously into >>>>>>> pointers, and if your integer can be so packed, you do it; >>>>>>> otherwise you use a reference to sime kind of INTEGER object >>>>>>> elsewhere. There are operations for packing integers and object >>>>>>> pointers into such words, and others for unpacking them >>>>>>> (complete >>>>>>> with >>>>>>> type-test). The actual physical representation can be >>>>>>> machine- or >>>>>>> implemetation dependent -- you could do a bit of shifting and >>>>>>> pack >>>>>>> integers into words with the low bit set (if pointers to objects >>>>>>> are >>>>>>> usually aligned in some way, the integers will stand out as >>>>>>> being >>>>>>> unalinged) Or you could use an uppoer bound on "small" >>>>>>> integers, >>>>>>> as C >>>>>>> does. And on a machine where such packing is impossible (for >>>>>>> whatever >>>>>>> reason) you could simply set the upper bound of (the absolute >>>>>>> alue >>>>>>> of) such packable integers to be zero, so there wouldn't be any. >>>>>>> >>>>>>> Is there any way such a thing can be done in Modula 3? Remember >>>>>>> -- >>>>>>> I do >>>>>>> want the garbage collector to be aware of such conventions and >>>>>>> do >>>>>>> proper >>>>>>> tracing on the pointers? >>>>>>> >>>>>>> (I suspect the answer is "no". But would be a pity.) >>>>>>> >>>>>>> -- hendrik >>>> >> From hendrik at topoi.pooq.com Mon Mar 30 15:19:18 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 30 Mar 2009 09:19:18 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> Message-ID: <20090330131918.GA6921@topoi.pooq.com> On Thu, Mar 26, 2009 at 02:08:00AM +0000, Jay wrote: > > > > svn is at least somewhat better than cvs. > > > > In http://gravityboy.livejournal.com/39755.html, gravityboy says > > > > : I'm really tired of people pushing the adoption of svn because it's a > > : better CVS. The only people who that argument hasn't swayed are those > > > > > That's ambiguous to me. > > He isn't clearly opposed to adopting svn over cvs, but svn over anything else. > > It doesn't matter what I think, but I'm definitely not opposed to monotone. > > Its marketing material reads among the best (seriously). > > > > > > I'm not volunteering to do any conversion, and I'm sure I (and others) will grumble no matter how painless switching clients is, but I'm pretty sure there are gains to be had and ignore at least my grumbling. > > I really don't like the web interface to CVS in particular. It doesn't let me identify "change sets" and view their diffs, I have to root around to all the files. Tinderbox does address this, on the side. (You would have to be sure, whatever replacement/conversion, included a web interface, anonymous read-only access, Tinderbox-or-other interop, etc.; imho you don't have to deliver all at once.) > > > > > > The source control systems that use "databases", which I think monotone does, do they interact poorly with backup (in particular, whatever backup Elegosoft uses)? You know -- an incremental backup system that looks at file times/sizes would end up always copying the entire thing. Even so, "databases" can be a good thing.. > > > > > > I understand that "two way migration" lets people keep using either > system, but I'm not sure that's worthwhile. On the other hand, if "the > new way" is read/write, and a "cvs mirror" is read only, except for > some blessed mirroring server, that should be fairly easy and have > some value. That can also be a way to ease the transition wrt > anonymous read-only access, Tinderbox interop, etc. Is CVS back up yet? Completely? I've been delaying trying the monotone conversion because it would be nice to have only one set of problems to look into. -- hendrik > > > > > > - Jay > > From jay.krell at cornell.edu Mon Mar 30 15:23:10 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 30 Mar 2009 13:23:10 +0000 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: This was surprisingly difficult. InitHandlers is called much earlier than InitActivations. InitActivations does a heap allocation. InitHandlers did not. The types involved are not yet initialized at this point, or somesuch. You cannot NEW(Activation) in the first call to PushFrame. So, maybe, use a global for the first one, but then what happens is it gets reinitialized later by the module initializer -- which is perhaps another indictment of initializers..or maybe a special case in the depths of the system -- this module and anything it uses are subject to be called by compiler-generated calls -- they can be called before their initializers run.. seems to me the initialization could have happened "statically" like in C. Anyway, I should have this done shortly. Trick is to use a local value and assign it to a heap block allocated directly with calloc instead of RTAllocator. The result is maybe faster, maybe slower. Before, "try" cost pthread_getspecific and setspecific. Now it will just cost getspecific. But with another pointer deref and call to GetActivation with its on-demand initialization. Before, popframe only called setspecific. Now it will only call getspecific, plus the indirect and on-demand initialization. The on-demand seems bogus in pop, given that push already had to occur. So maybe that could be optimized. This stuff is highly optimized in C and C++ on NT.. NT/x86 has a special thread local just for exception handling, faster than all other thread locals. All non-x86 NT platforms have stack walkers -- no cost for "try", and then "throw" maps instruction pointer to data about how to to unwind the stack, using a little mini-assembly code. - Jay ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 19 Mar 2009 01:03:57 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] per thread data? > > > > > > > > > Thanks, I should get around to that "soon" then. > > > > - Jay > > > > ________________________________ > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 19 Mar 2009 10:14:59 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] per thread data? > > I have no problem putting the exception handler stack thread local into the activation thread local. > > > > > > > On 18 Mar 2009, at 20:11, Jay wrote: > > > > I'm not looking at it right now, but doesn't seem rather piggy to have two thread locals and data on the side? > > > I'm guessing the data on the side is needed because we need to be able to enumerate our threads, to suspend them all? > > > I understand that having multiple thread locals optimizes their use, but it seems greedy. > vs. a small heap allocation that combines them. > > Or in fact.. presumably there could just be one thread local that is the thread pointer, and the handler link could be put at the start, for architectures where zero offset is smaller/faster than non-zero offset. > > > Another idea, of course, is to look into "__thread", "__declspec(thread)". > > On Windows and probably all platforms they exist on, they are nicely more efficient than pthread_get/setspecific, except on Windows they don't really work acceptably prior to Vista -- they only work in .exes and their static dependencies, not any .dll you load after the process starts with LoadLibrary (dlopen). > > > Does "__thread" work well on most non-Windows platforms? > i.e. even if shared object is loaded with dlopen? > > > I could have sworn I saw code out there that was "adaptive". > It easily/efficiently checked if it was loaded with LoadLibrary or not. > If so, it'd TlsGet/SetValue (pthread_get/setspecific). > If not, it'd use __declspec(thread) (__thread). > The check was based on if __tlsindex was not zero or somesuch. I couldn't track it down though. > > > In either case, yes, I know, one of the thread locals at least is gone on platforms that have stack walkers, e.g. Solaris, and potentially NT, and maybe others. > > > - Jay > > From jay.krell at cornell.edu Tue Mar 31 00:15:29 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 30 Mar 2009 22:15:29 +0000 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: hm, thinking about this more... What about threads not created by Modula-3 Fork() (or the first thread)? It looks like exception handling had a chance of working on them before. Now they'll crash upon entering functions with try or raise or I presume lock. 1) ok? 2) do the heap alloc on demand? But is that enough? Can it be initialized without further context? Let's see..the circular list can be maintained without further context. handle := pthread_self, ok. stack can probably be figured out, though that is probably just for gc and could be left alone for now, continuing to not work (or fixed)...getcontext at least on some platforms can fill this in, or VirtualQuery/msomething (mmap family?)? 3) put back the second thread local? #2 has a chance of working better than before -- letting GC work on threads not created by Modula-3 runtime, something that has long bothered me...but I haven't done a complete analysis. Or at least maybe keep it working as it was For now there is somewhat of a regression, ie, when calling Modula-3 code on threads not created from Modula-3. Possibly the gc in this case was already dangerous? Failing to find references on other stacks? Or failing all allocations (should be easy to check but I have to run..) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] per thread data? > Date: Mon, 30 Mar 2009 13:23:10 +0000 > > > This was surprisingly difficult. > > > InitHandlers is called much earlier than InitActivations. > InitActivations does a heap allocation. > InitHandlers did not. > The types involved are not yet initialized at this point, or somesuch. > You cannot NEW(Activation) in the first call to PushFrame. > So, maybe, use a global for the first one, > but then what happens is it gets reinitialized later by > the module initializer -- which is perhaps another indictment > of initializers..or maybe a special case in the depths of the system -- > this module and anything it uses are subject to be called by > compiler-generated calls -- they can be called before their initializers > run.. seems to me the initialization could have happened "statically" > like in C. > > > Anyway, I should have this done shortly. > Trick is to use a local value and assign it to a heap block > allocated directly with calloc instead of RTAllocator. > > > The result is maybe faster, maybe slower. > Before, "try" cost pthread_getspecific and setspecific. > Now it will just cost getspecific. > But with another pointer deref and call to GetActivation > with its on-demand initialization. > > > Before, popframe only called setspecific. > Now it will only call getspecific, plus the indirect > and on-demand initialization. > The on-demand seems bogus in pop, given that push already had to occur. > So maybe that could be optimized. > > > This stuff is highly optimized in C and C++ on NT.. > NT/x86 has a special thread local just for exception handling, > faster than all other thread locals. > All non-x86 NT platforms have stack walkers -- no cost for "try", > and then "throw" maps instruction pointer to data about how to > to unwind the stack, using a little mini-assembly code. > > > - Jay > > > ________________________________ >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Thu, 19 Mar 2009 01:03:57 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] per thread data? >> >> >> >> >> >> >> >> >> Thanks, I should get around to that "soon" then. >> >> >> >> - Jay >> >> >> >> ________________________________ >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Thu, 19 Mar 2009 10:14:59 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] per thread data? >> >> I have no problem putting the exception handler stack thread local into the activation thread local. >> >> >> >> >> >> >> On 18 Mar 2009, at 20:11, Jay wrote: >> >> >> >> I'm not looking at it right now, but doesn't seem rather piggy to have two thread locals and data on the side? >> >> >> I'm guessing the data on the side is needed because we need to be able to enumerate our threads, to suspend them all? >> >> >> I understand that having multiple thread locals optimizes their use, but it seems greedy. >> vs. a small heap allocation that combines them. >> >> Or in fact.. presumably there could just be one thread local that is the thread pointer, and the handler link could be put at the start, for architectures where zero offset is smaller/faster than non-zero offset. >> >> >> Another idea, of course, is to look into "__thread", "__declspec(thread)". >> >> On Windows and probably all platforms they exist on, they are nicely more efficient than pthread_get/setspecific, except on Windows they don't really work acceptably prior to Vista -- they only work in .exes and their static dependencies, not any .dll you load after the process starts with LoadLibrary (dlopen). >> >> >> Does "__thread" work well on most non-Windows platforms? >> i.e. even if shared object is loaded with dlopen? >> >> >> I could have sworn I saw code out there that was "adaptive". >> It easily/efficiently checked if it was loaded with LoadLibrary or not. >> If so, it'd TlsGet/SetValue (pthread_get/setspecific). >> If not, it'd use __declspec(thread) (__thread). >> The check was based on if __tlsindex was not zero or somesuch. I couldn't track it down though. >> >> >> In either case, yes, I know, one of the thread locals at least is gone on platforms that have stack walkers, e.g. Solaris, and potentially NT, and maybe others. >> >> >> - Jay >> >> From hosking at cs.purdue.edu Tue Mar 31 00:42:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Mar 2009 09:42:06 +1100 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: Yes, this is a tricky issue. At some point I seem to recall it being OK to have non-Modula-3 threads start running Modula-3 code, but I don't know for sure. I've never really liked the idea of having non- M3 threads. Are you using the existing handler maps and exception stack unwinding support for non-x86 NT? On 31 Mar 2009, at 09:15, Jay wrote: > > hm, thinking about this more... > What about threads not created by Modula-3 Fork() (or the first > thread)? > > It looks like exception handling had a chance of working on them > before. Now they'll crash upon entering functions > with try or raise or I presume lock. > > > 1) ok? > > > 2) do the heap alloc on demand? > But is that enough? Can it be initialized without further context? > Let's see..the circular list can be maintained without further > context. > handle := pthread_self, ok. stack can probably be figured out, though > that is probably just for gc and could be left alone for now, > continuing > to not work (or fixed)...getcontext at least on some platforms can > fill this in, or VirtualQuery/msomething (mmap family?)? > > > 3) put back the second thread local? > > > #2 has a chance of working better than before -- letting GC > work on threads not created by Modula-3 runtime, something > that has long bothered me...but I haven't done a complete analysis. > Or at least maybe keep it working as it was > For now there is somewhat of a regression, ie, when calling > Modula-3 code on threads not created from Modula-3. > Possibly the gc in this case was already dangerous? > Failing to find references on other stacks? > Or failing all allocations (should be easy to check but I have to > run..) > > > - Jay > > > > > > > > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] per thread data? >> Date: Mon, 30 Mar 2009 13:23:10 +0000 >> >> >> This was surprisingly difficult. >> >> >> InitHandlers is called much earlier than InitActivations. >> InitActivations does a heap allocation. >> InitHandlers did not. >> The types involved are not yet initialized at this point, or >> somesuch. >> You cannot NEW(Activation) in the first call to PushFrame. >> So, maybe, use a global for the first one, >> but then what happens is it gets reinitialized later by >> the module initializer -- which is perhaps another indictment >> of initializers..or maybe a special case in the depths of the >> system -- >> this module and anything it uses are subject to be called by >> compiler-generated calls -- they can be called before their >> initializers >> run.. seems to me the initialization could have happened "statically" >> like in C. >> >> >> Anyway, I should have this done shortly. >> Trick is to use a local value and assign it to a heap block >> allocated directly with calloc instead of RTAllocator. >> >> >> The result is maybe faster, maybe slower. >> Before, "try" cost pthread_getspecific and setspecific. >> Now it will just cost getspecific. >> But with another pointer deref and call to GetActivation >> with its on-demand initialization. >> >> >> Before, popframe only called setspecific. >> Now it will only call getspecific, plus the indirect >> and on-demand initialization. >> The on-demand seems bogus in pop, given that push already had to >> occur. >> So maybe that could be optimized. >> >> >> This stuff is highly optimized in C and C++ on NT.. >> NT/x86 has a special thread local just for exception handling, >> faster than all other thread locals. >> All non-x86 NT platforms have stack walkers -- no cost for "try", >> and then "throw" maps instruction pointer to data about how to >> to unwind the stack, using a little mini-assembly code. >> >> >> - Jay >> >> >> ________________________________ >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Thu, 19 Mar 2009 01:03:57 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] per thread data? >>> >>> >>> >>> >>> >>> >>> >>> >>> Thanks, I should get around to that "soon" then. >>> >>> >>> >>> - Jay >>> >>> >>> >>> ________________________________ >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Thu, 19 Mar 2009 10:14:59 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] per thread data? >>> >>> I have no problem putting the exception handler stack thread local >>> into the activation thread local. >>> >>> >>> >>> >>> >>> >>> On 18 Mar 2009, at 20:11, Jay wrote: >>> >>> >>> >>> I'm not looking at it right now, but doesn't seem rather piggy to >>> have two thread locals and data on the side? >>> >>> >>> I'm guessing the data on the side is needed because we need to be >>> able to enumerate our threads, to suspend them all? >>> >>> >>> I understand that having multiple thread locals optimizes their >>> use, but it seems greedy. >>> vs. a small heap allocation that combines them. >>> >>> Or in fact.. presumably there could just be one thread local that >>> is the thread pointer, and the handler link could be put at the >>> start, for architectures where zero offset is smaller/faster than >>> non-zero offset. >>> >>> >>> Another idea, of course, is to look into "__thread", >>> "__declspec(thread)". >>> >>> On Windows and probably all platforms they exist on, they are >>> nicely more efficient than pthread_get/setspecific, except on >>> Windows they don't really work acceptably prior to Vista -- they >>> only work in .exes and their static dependencies, not any .dll you >>> load after the process starts with LoadLibrary (dlopen). >>> >>> >>> Does "__thread" work well on most non-Windows platforms? >>> i.e. even if shared object is loaded with dlopen? >>> >>> >>> I could have sworn I saw code out there that was "adaptive". >>> It easily/efficiently checked if it was loaded with LoadLibrary or >>> not. >>> If so, it'd TlsGet/SetValue (pthread_get/setspecific). >>> If not, it'd use __declspec(thread) (__thread). >>> The check was based on if __tlsindex was not zero or somesuch. I >>> couldn't track it down though. >>> >>> >>> In either case, yes, I know, one of the thread locals at least is >>> gone on platforms that have stack walkers, e.g. Solaris, and >>> potentially NT, and maybe others. >>> >>> >>> - Jay >>> >>> From hosking at cs.purdue.edu Tue Mar 31 00:44:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Mar 2009 09:44:02 +1100 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: <6B76EEF4-F926-4CF6-AF77-0D32A4A7D438@cs.purdue.edu> I am a little uneasy about calloc being used instead of RTAllocator. We lose the single point of allocation that is useful for all sorts of things like accounting, etc. I'll take a look at what you have done and think about it some... On 31 Mar 2009, at 09:15, Jay wrote: > > hm, thinking about this more... > What about threads not created by Modula-3 Fork() (or the first > thread)? > > > It looks like exception handling had a chance of working on them > before. Now they'll crash upon entering functions > with try or raise or I presume lock. > > > 1) ok? > > > 2) do the heap alloc on demand? > But is that enough? Can it be initialized without further context? > Let's see..the circular list can be maintained without further > context. > handle := pthread_self, ok. stack can probably be figured out, though > that is probably just for gc and could be left alone for now, > continuing > to not work (or fixed)...getcontext at least on some platforms can > fill this in, or VirtualQuery/msomething (mmap family?)? > > > 3) put back the second thread local? > > > #2 has a chance of working better than before -- letting GC > work on threads not created by Modula-3 runtime, something > that has long bothered me...but I haven't done a complete analysis. > Or at least maybe keep it working as it was > For now there is somewhat of a regression, ie, when calling > Modula-3 code on threads not created from Modula-3. > Possibly the gc in this case was already dangerous? > Failing to find references on other stacks? > Or failing all allocations (should be easy to check but I have to > run..) > > > - Jay > > > > > > > > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] per thread data? >> Date: Mon, 30 Mar 2009 13:23:10 +0000 >> >> >> This was surprisingly difficult. >> >> >> InitHandlers is called much earlier than InitActivations. >> InitActivations does a heap allocation. >> InitHandlers did not. >> The types involved are not yet initialized at this point, or >> somesuch. >> You cannot NEW(Activation) in the first call to PushFrame. >> So, maybe, use a global for the first one, >> but then what happens is it gets reinitialized later by >> the module initializer -- which is perhaps another indictment >> of initializers..or maybe a special case in the depths of the >> system -- >> this module and anything it uses are subject to be called by >> compiler-generated calls -- they can be called before their >> initializers >> run.. seems to me the initialization could have happened "statically" >> like in C. >> >> >> Anyway, I should have this done shortly. >> Trick is to use a local value and assign it to a heap block >> allocated directly with calloc instead of RTAllocator. >> >> >> The result is maybe faster, maybe slower. >> Before, "try" cost pthread_getspecific and setspecific. >> Now it will just cost getspecific. >> But with another pointer deref and call to GetActivation >> with its on-demand initialization. >> >> >> Before, popframe only called setspecific. >> Now it will only call getspecific, plus the indirect >> and on-demand initialization. >> The on-demand seems bogus in pop, given that push already had to >> occur. >> So maybe that could be optimized. >> >> >> This stuff is highly optimized in C and C++ on NT.. >> NT/x86 has a special thread local just for exception handling, >> faster than all other thread locals. >> All non-x86 NT platforms have stack walkers -- no cost for "try", >> and then "throw" maps instruction pointer to data about how to >> to unwind the stack, using a little mini-assembly code. >> >> >> - Jay >> >> >> ________________________________ >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Thu, 19 Mar 2009 01:03:57 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] per thread data? >>> >>> >>> >>> >>> >>> >>> >>> >>> Thanks, I should get around to that "soon" then. >>> >>> >>> >>> - Jay >>> >>> >>> >>> ________________________________ >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Thu, 19 Mar 2009 10:14:59 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] per thread data? >>> >>> I have no problem putting the exception handler stack thread local >>> into the activation thread local. >>> >>> >>> >>> >>> >>> >>> On 18 Mar 2009, at 20:11, Jay wrote: >>> >>> >>> >>> I'm not looking at it right now, but doesn't seem rather piggy to >>> have two thread locals and data on the side? >>> >>> >>> I'm guessing the data on the side is needed because we need to be >>> able to enumerate our threads, to suspend them all? >>> >>> >>> I understand that having multiple thread locals optimizes their >>> use, but it seems greedy. >>> vs. a small heap allocation that combines them. >>> >>> Or in fact.. presumably there could just be one thread local that >>> is the thread pointer, and the handler link could be put at the >>> start, for architectures where zero offset is smaller/faster than >>> non-zero offset. >>> >>> >>> Another idea, of course, is to look into "__thread", >>> "__declspec(thread)". >>> >>> On Windows and probably all platforms they exist on, they are >>> nicely more efficient than pthread_get/setspecific, except on >>> Windows they don't really work acceptably prior to Vista -- they >>> only work in .exes and their static dependencies, not any .dll you >>> load after the process starts with LoadLibrary (dlopen). >>> >>> >>> Does "__thread" work well on most non-Windows platforms? >>> i.e. even if shared object is loaded with dlopen? >>> >>> >>> I could have sworn I saw code out there that was "adaptive". >>> It easily/efficiently checked if it was loaded with LoadLibrary or >>> not. >>> If so, it'd TlsGet/SetValue (pthread_get/setspecific). >>> If not, it'd use __declspec(thread) (__thread). >>> The check was based on if __tlsindex was not zero or somesuch. I >>> couldn't track it down though. >>> >>> >>> In either case, yes, I know, one of the thread locals at least is >>> gone on platforms that have stack walkers, e.g. Solaris, and >>> potentially NT, and maybe others. >>> >>> >>> - Jay >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Mar 31 00:45:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Mar 2009 09:45:22 +1100 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: <21521BC5-BC0A-4852-A624-AF948D66C575@cs.purdue.edu> PS In general, I am loathe to make changes that complicate the code based on performance assumptions that are only hypothetical. Better to profile and see where the time is going before prematurely "optimizing". On 31 Mar 2009, at 09:42, Tony Hosking wrote: > Yes, this is a tricky issue. At some point I seem to recall it > being OK to have non-Modula-3 threads start running Modula-3 code, > but I don't know for sure. I've never really liked the idea of > having non-M3 threads. > > Are you using the existing handler maps and exception stack > unwinding support for non-x86 NT? > > On 31 Mar 2009, at 09:15, Jay wrote: > >> >> hm, thinking about this more... >> What about threads not created by Modula-3 Fork() (or the first >> thread)? >> >> It looks like exception handling had a chance of working on them >> before. Now they'll crash upon entering functions >> with try or raise or I presume lock. >> >> >> 1) ok? >> >> >> 2) do the heap alloc on demand? >> But is that enough? Can it be initialized without further context? >> Let's see..the circular list can be maintained without further >> context. >> handle := pthread_self, ok. stack can probably be figured out, though >> that is probably just for gc and could be left alone for now, >> continuing >> to not work (or fixed)...getcontext at least on some platforms can >> fill this in, or VirtualQuery/msomething (mmap family?)? >> >> >> 3) put back the second thread local? >> >> >> #2 has a chance of working better than before -- letting GC >> work on threads not created by Modula-3 runtime, something >> that has long bothered me...but I haven't done a complete analysis. >> Or at least maybe keep it working as it was >> For now there is somewhat of a regression, ie, when calling >> Modula-3 code on threads not created from Modula-3. >> Possibly the gc in this case was already dangerous? >> Failing to find references on other stacks? >> Or failing all allocations (should be easy to check but I have to >> run..) >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] per thread data? >>> Date: Mon, 30 Mar 2009 13:23:10 +0000 >>> >>> >>> This was surprisingly difficult. >>> >>> >>> InitHandlers is called much earlier than InitActivations. >>> InitActivations does a heap allocation. >>> InitHandlers did not. >>> The types involved are not yet initialized at this point, or >>> somesuch. >>> You cannot NEW(Activation) in the first call to PushFrame. >>> So, maybe, use a global for the first one, >>> but then what happens is it gets reinitialized later by >>> the module initializer -- which is perhaps another indictment >>> of initializers..or maybe a special case in the depths of the >>> system -- >>> this module and anything it uses are subject to be called by >>> compiler-generated calls -- they can be called before their >>> initializers >>> run.. seems to me the initialization could have happened >>> "statically" >>> like in C. >>> >>> >>> Anyway, I should have this done shortly. >>> Trick is to use a local value and assign it to a heap block >>> allocated directly with calloc instead of RTAllocator. >>> >>> >>> The result is maybe faster, maybe slower. >>> Before, "try" cost pthread_getspecific and setspecific. >>> Now it will just cost getspecific. >>> But with another pointer deref and call to GetActivation >>> with its on-demand initialization. >>> >>> >>> Before, popframe only called setspecific. >>> Now it will only call getspecific, plus the indirect >>> and on-demand initialization. >>> The on-demand seems bogus in pop, given that push already had to >>> occur. >>> So maybe that could be optimized. >>> >>> >>> This stuff is highly optimized in C and C++ on NT.. >>> NT/x86 has a special thread local just for exception handling, >>> faster than all other thread locals. >>> All non-x86 NT platforms have stack walkers -- no cost for "try", >>> and then "throw" maps instruction pointer to data about how to >>> to unwind the stack, using a little mini-assembly code. >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Thu, 19 Mar 2009 01:03:57 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] per thread data? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thanks, I should get around to that "soon" then. >>>> >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Thu, 19 Mar 2009 10:14:59 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] per thread data? >>>> >>>> I have no problem putting the exception handler stack thread >>>> local into the activation thread local. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 18 Mar 2009, at 20:11, Jay wrote: >>>> >>>> >>>> >>>> I'm not looking at it right now, but doesn't seem rather piggy to >>>> have two thread locals and data on the side? >>>> >>>> >>>> I'm guessing the data on the side is needed because we need to be >>>> able to enumerate our threads, to suspend them all? >>>> >>>> >>>> I understand that having multiple thread locals optimizes their >>>> use, but it seems greedy. >>>> vs. a small heap allocation that combines them. >>>> >>>> Or in fact.. presumably there could just be one thread local that >>>> is the thread pointer, and the handler link could be put at the >>>> start, for architectures where zero offset is smaller/faster than >>>> non-zero offset. >>>> >>>> >>>> Another idea, of course, is to look into "__thread", >>>> "__declspec(thread)". >>>> >>>> On Windows and probably all platforms they exist on, they are >>>> nicely more efficient than pthread_get/setspecific, except on >>>> Windows they don't really work acceptably prior to Vista -- they >>>> only work in .exes and their static dependencies, not any .dll >>>> you load after the process starts with LoadLibrary (dlopen). >>>> >>>> >>>> Does "__thread" work well on most non-Windows platforms? >>>> i.e. even if shared object is loaded with dlopen? >>>> >>>> >>>> I could have sworn I saw code out there that was "adaptive". >>>> It easily/efficiently checked if it was loaded with LoadLibrary >>>> or not. >>>> If so, it'd TlsGet/SetValue (pthread_get/setspecific). >>>> If not, it'd use __declspec(thread) (__thread). >>>> The check was based on if __tlsindex was not zero or somesuch. I >>>> couldn't track it down though. >>>> >>>> >>>> In either case, yes, I know, one of the thread locals at least is >>>> gone on platforms that have stack walkers, e.g. Solaris, and >>>> potentially NT, and maybe others. >>>> >>>> >>>> - Jay >>>> >>>> From jay.krell at cornell.edu Tue Mar 31 02:06:04 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 00:06:04 +0000 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: My point about optimized thread locals was about C and C++. (And not gcc, at that.) Modula-3 on NT is the same as "all" platforms, except, I guess, Solaris/SPARC32. No stack walker. Highly inefficient pushframe/popframe using general thread locals -- pthread_getspecific/setspecific / TlsGetValue/SetValue -- pthreads and Win32 are very analogous here. There is only NT/x86 for Modula-3 so far. I'm not sure gcc for NT/amd64 is mature enough, and haven't seen any signs of NT/IA64 (nor Alpha/PPC/MIPS...). gcc on NT/x86 has its own other two EH mechanisms -- setjmp/longjmp and I presume a stack walking implementation. Most other compilers are like Visual C++ -- e.g. OpenWatcom and DigitalMars. CodeWarrior had two settings, I think one matched Visual C++. There should really be just one implementation of this across all languages. NT's setjmp/longjmp do interoperate with exceptions at least, so you can use a portable slow form and still interoperate..well, there are two versions, one that does, one that doesn't. I need to switch Modula-3 to the interoperable form. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] per thread data? > Date: Tue, 31 Mar 2009 09:42:06 +1100 > > Yes, this is a tricky issue. At some point I seem to recall it being > OK to have non-Modula-3 threads start running Modula-3 code, but I > don't know for sure. I've never really liked the idea of having non- > M3 threads. > > Are you using the existing handler maps and exception stack unwinding > support for non-x86 NT? > > On 31 Mar 2009, at 09:15, Jay wrote: > > > > > hm, thinking about this more... > > What about threads not created by Modula-3 Fork() (or the first > > thread)? > > > > It looks like exception handling had a chance of working on them > > before. Now they'll crash upon entering functions > > with try or raise or I presume lock. > > > > > > 1) ok? > > > > > > 2) do the heap alloc on demand? > > But is that enough? Can it be initialized without further context? > > Let's see..the circular list can be maintained without further > > context. > > handle := pthread_self, ok. stack can probably be figured out, though > > that is probably just for gc and could be left alone for now, > > continuing > > to not work (or fixed)...getcontext at least on some platforms can > > fill this in, or VirtualQuery/msomething (mmap family?)? > > > > > > 3) put back the second thread local? > > > > > > #2 has a chance of working better than before -- letting GC > > work on threads not created by Modula-3 runtime, something > > that has long bothered me...but I haven't done a complete analysis. > > Or at least maybe keep it working as it was > > For now there is somewhat of a regression, ie, when calling > > Modula-3 code on threads not created from Modula-3. > > Possibly the gc in this case was already dangerous? > > Failing to find references on other stacks? > > Or failing all allocations (should be easy to check but I have to > > run..) > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu > >> CC: m3devel at elegosoft.com > >> Subject: RE: [M3devel] per thread data? > >> Date: Mon, 30 Mar 2009 13:23:10 +0000 > >> > >> > >> This was surprisingly difficult. > >> > >> > >> InitHandlers is called much earlier than InitActivations. > >> InitActivations does a heap allocation. > >> InitHandlers did not. > >> The types involved are not yet initialized at this point, or > >> somesuch. > >> You cannot NEW(Activation) in the first call to PushFrame. > >> So, maybe, use a global for the first one, > >> but then what happens is it gets reinitialized later by > >> the module initializer -- which is perhaps another indictment > >> of initializers..or maybe a special case in the depths of the > >> system -- > >> this module and anything it uses are subject to be called by > >> compiler-generated calls -- they can be called before their > >> initializers > >> run.. seems to me the initialization could have happened "statically" > >> like in C. > >> > >> > >> Anyway, I should have this done shortly. > >> Trick is to use a local value and assign it to a heap block > >> allocated directly with calloc instead of RTAllocator. > >> > >> > >> The result is maybe faster, maybe slower. > >> Before, "try" cost pthread_getspecific and setspecific. > >> Now it will just cost getspecific. > >> But with another pointer deref and call to GetActivation > >> with its on-demand initialization. > >> > >> > >> Before, popframe only called setspecific. > >> Now it will only call getspecific, plus the indirect > >> and on-demand initialization. > >> The on-demand seems bogus in pop, given that push already had to > >> occur. > >> So maybe that could be optimized. > >> > >> > >> This stuff is highly optimized in C and C++ on NT.. > >> NT/x86 has a special thread local just for exception handling, > >> faster than all other thread locals. > >> All non-x86 NT platforms have stack walkers -- no cost for "try", > >> and then "throw" maps instruction pointer to data about how to > >> to unwind the stack, using a little mini-assembly code. > >> > >> > >> - Jay > >> > >> > >> ________________________________ > >>> From: jay.krell at cornell.edu > >>> To: hosking at cs.purdue.edu > >>> Date: Thu, 19 Mar 2009 01:03:57 +0000 > >>> CC: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] per thread data? > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Thanks, I should get around to that "soon" then. > >>> > >>> > >>> > >>> - Jay > >>> > >>> > >>> > >>> ________________________________ > >>> > >>> From: hosking at cs.purdue.edu > >>> To: jay.krell at cornell.edu > >>> Date: Thu, 19 Mar 2009 10:14:59 +1100 > >>> CC: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] per thread data? > >>> > >>> I have no problem putting the exception handler stack thread local > >>> into the activation thread local. > >>> > >>> > >>> > >>> > >>> > >>> > >>> On 18 Mar 2009, at 20:11, Jay wrote: > >>> > >>> > >>> > >>> I'm not looking at it right now, but doesn't seem rather piggy to > >>> have two thread locals and data on the side? > >>> > >>> > >>> I'm guessing the data on the side is needed because we need to be > >>> able to enumerate our threads, to suspend them all? > >>> > >>> > >>> I understand that having multiple thread locals optimizes their > >>> use, but it seems greedy. > >>> vs. a small heap allocation that combines them. > >>> > >>> Or in fact.. presumably there could just be one thread local that > >>> is the thread pointer, and the handler link could be put at the > >>> start, for architectures where zero offset is smaller/faster than > >>> non-zero offset. > >>> > >>> > >>> Another idea, of course, is to look into "__thread", > >>> "__declspec(thread)". > >>> > >>> On Windows and probably all platforms they exist on, they are > >>> nicely more efficient than pthread_get/setspecific, except on > >>> Windows they don't really work acceptably prior to Vista -- they > >>> only work in .exes and their static dependencies, not any .dll you > >>> load after the process starts with LoadLibrary (dlopen). > >>> > >>> > >>> Does "__thread" work well on most non-Windows platforms? > >>> i.e. even if shared object is loaded with dlopen? > >>> > >>> > >>> I could have sworn I saw code out there that was "adaptive". > >>> It easily/efficiently checked if it was loaded with LoadLibrary or > >>> not. > >>> If so, it'd TlsGet/SetValue (pthread_get/setspecific). > >>> If not, it'd use __declspec(thread) (__thread). > >>> The check was based on if __tlsindex was not zero or somesuch. I > >>> couldn't track it down though. > >>> > >>> > >>> In either case, yes, I know, one of the thread locals at least is > >>> gone on platforms that have stack walkers, e.g. Solaris, and > >>> potentially NT, and maybe others. > >>> > >>> > >>> - Jay > >>> > >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 31 02:12:25 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 00:12:25 +0000 Subject: [M3devel] per thread data? In-Reply-To: <21521BC5-BC0A-4852-A624-AF948D66C575@cs.purdue.edu> References: <21521BC5-BC0A-4852-A624-AF948D66C575@cs.purdue.edu> Message-ID: > > but I don't know for sure. I've never really liked the idea of > > having non-M3 threads. I understand there is no free lunch, but the scenario is that I write a "plugin" in Modula-3. Or even a static dependency -- the point being, to mix languages and have the "primary" language not be Modula-3. For folks to be able to call "native" pthread_create or Win32 CreateThread, and still be able to use Modula-3. On Win32, .dlls have a callback that gets called for every thread created. Generally they can initializer their per-thread data there. There is also a callback for thread exit. It is a slightly thorny issue though, for a few reasons. For example, if .dlls get dynamically loaded/unloaded, threads can be created before they load -- no callback, or threads can be exited after they unload -- again, no callback. You only get callbacks when you are already loaded at the time of thread create/exit. You can also initialize on demand, assuming there is enough memory still. If the primary executable is not written in Modula-3, but has a static dependency on a Modula-3 .dll, then it works ok. - Jay > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 31 Mar 2009 09:45:22 +1100 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] per thread data? > > PS In general, I am loathe to make changes that complicate the code > based on performance assumptions that are only hypothetical. Better > to profile and see where the time is going before prematurely > "optimizing". > > On 31 Mar 2009, at 09:42, Tony Hosking wrote: > > > Yes, this is a tricky issue. At some point I seem to recall it > > being OK to have non-Modula-3 threads start running Modula-3 code, > > but I don't know for sure. I've never really liked the idea of > > having non-M3 threads. > > > > Are you using the existing handler maps and exception stack > > unwinding support for non-x86 NT? > > > > On 31 Mar 2009, at 09:15, Jay wrote: > > > >> > >> hm, thinking about this more... > >> What about threads not created by Modula-3 Fork() (or the first > >> thread)? > >> > >> It looks like exception handling had a chance of working on them > >> before. Now they'll crash upon entering functions > >> with try or raise or I presume lock. > >> > >> > >> 1) ok? > >> > >> > >> 2) do the heap alloc on demand? > >> But is that enough? Can it be initialized without further context? > >> Let's see..the circular list can be maintained without further > >> context. > >> handle := pthread_self, ok. stack can probably be figured out, though > >> that is probably just for gc and could be left alone for now, > >> continuing > >> to not work (or fixed)...getcontext at least on some platforms can > >> fill this in, or VirtualQuery/msomething (mmap family?)? > >> > >> > >> 3) put back the second thread local? > >> > >> > >> #2 has a chance of working better than before -- letting GC > >> work on threads not created by Modula-3 runtime, something > >> that has long bothered me...but I haven't done a complete analysis. > >> Or at least maybe keep it working as it was > >> For now there is somewhat of a regression, ie, when calling > >> Modula-3 code on threads not created from Modula-3. > >> Possibly the gc in this case was already dangerous? > >> Failing to find references on other stacks? > >> Or failing all allocations (should be easy to check but I have to > >> run..) > >> > >> > >> - Jay > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> ---------------------------------------- > >>> From: jay.krell at cornell.edu > >>> To: hosking at cs.purdue.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: RE: [M3devel] per thread data? > >>> Date: Mon, 30 Mar 2009 13:23:10 +0000 > >>> > >>> > >>> This was surprisingly difficult. > >>> > >>> > >>> InitHandlers is called much earlier than InitActivations. > >>> InitActivations does a heap allocation. > >>> InitHandlers did not. > >>> The types involved are not yet initialized at this point, or > >>> somesuch. > >>> You cannot NEW(Activation) in the first call to PushFrame. > >>> So, maybe, use a global for the first one, > >>> but then what happens is it gets reinitialized later by > >>> the module initializer -- which is perhaps another indictment > >>> of initializers..or maybe a special case in the depths of the > >>> system -- > >>> this module and anything it uses are subject to be called by > >>> compiler-generated calls -- they can be called before their > >>> initializers > >>> run.. seems to me the initialization could have happened > >>> "statically" > >>> like in C. > >>> > >>> > >>> Anyway, I should have this done shortly. > >>> Trick is to use a local value and assign it to a heap block > >>> allocated directly with calloc instead of RTAllocator. > >>> > >>> > >>> The result is maybe faster, maybe slower. > >>> Before, "try" cost pthread_getspecific and setspecific. > >>> Now it will just cost getspecific. > >>> But with another pointer deref and call to GetActivation > >>> with its on-demand initialization. > >>> > >>> > >>> Before, popframe only called setspecific. > >>> Now it will only call getspecific, plus the indirect > >>> and on-demand initialization. > >>> The on-demand seems bogus in pop, given that push already had to > >>> occur. > >>> So maybe that could be optimized. > >>> > >>> > >>> This stuff is highly optimized in C and C++ on NT.. > >>> NT/x86 has a special thread local just for exception handling, > >>> faster than all other thread locals. > >>> All non-x86 NT platforms have stack walkers -- no cost for "try", > >>> and then "throw" maps instruction pointer to data about how to > >>> to unwind the stack, using a little mini-assembly code. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ________________________________ > >>>> From: jay.krell at cornell.edu > >>>> To: hosking at cs.purdue.edu > >>>> Date: Thu, 19 Mar 2009 01:03:57 +0000 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] per thread data? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Thanks, I should get around to that "soon" then. > >>>> > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> ________________________________ > >>>> > >>>> From: hosking at cs.purdue.edu > >>>> To: jay.krell at cornell.edu > >>>> Date: Thu, 19 Mar 2009 10:14:59 +1100 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] per thread data? > >>>> > >>>> I have no problem putting the exception handler stack thread > >>>> local into the activation thread local. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On 18 Mar 2009, at 20:11, Jay wrote: > >>>> > >>>> > >>>> > >>>> I'm not looking at it right now, but doesn't seem rather piggy to > >>>> have two thread locals and data on the side? > >>>> > >>>> > >>>> I'm guessing the data on the side is needed because we need to be > >>>> able to enumerate our threads, to suspend them all? > >>>> > >>>> > >>>> I understand that having multiple thread locals optimizes their > >>>> use, but it seems greedy. > >>>> vs. a small heap allocation that combines them. > >>>> > >>>> Or in fact.. presumably there could just be one thread local that > >>>> is the thread pointer, and the handler link could be put at the > >>>> start, for architectures where zero offset is smaller/faster than > >>>> non-zero offset. > >>>> > >>>> > >>>> Another idea, of course, is to look into "__thread", > >>>> "__declspec(thread)". > >>>> > >>>> On Windows and probably all platforms they exist on, they are > >>>> nicely more efficient than pthread_get/setspecific, except on > >>>> Windows they don't really work acceptably prior to Vista -- they > >>>> only work in .exes and their static dependencies, not any .dll > >>>> you load after the process starts with LoadLibrary (dlopen). > >>>> > >>>> > >>>> Does "__thread" work well on most non-Windows platforms? > >>>> i.e. even if shared object is loaded with dlopen? > >>>> > >>>> > >>>> I could have sworn I saw code out there that was "adaptive". > >>>> It easily/efficiently checked if it was loaded with LoadLibrary > >>>> or not. > >>>> If so, it'd TlsGet/SetValue (pthread_get/setspecific). > >>>> If not, it'd use __declspec(thread) (__thread). > >>>> The check was based on if __tlsindex was not zero or somesuch. I > >>>> couldn't track it down though. > >>>> > >>>> > >>>> In either case, yes, I know, one of the thread locals at least is > >>>> gone on platforms that have stack walkers, e.g. Solaris, and > >>>> potentially NT, and maybe others. > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 31 02:25:44 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 00:25:44 +0000 Subject: [M3devel] FW: per thread data? In-Reply-To: <21521BC5-BC0A-4852-A624-AF948D66C575@cs.purdue.edu> References: <21521BC5-BC0A-4852-A624-AF948D66C575@cs.purdue.edu> Message-ID: [truncated again] From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] per thread data? Date: Tue, 31 Mar 2009 00:12:25 +0000 > > but I don't know for sure. I've never really liked the idea of > > having non-M3 threads. I understand there is no free lunch, but the scenario is that I write a "plugin" in Modula-3. Or even a static dependency -- the point being, to mix languages and have the "primary" language not be Modula-3. For folks to be able to call "native" pthread_create or Win32 CreateThread, and still be able to use Modula-3. On Win32, .dlls have a callback that gets called for every thread created. Generally they can initializer their per-thread data there. There is also a callback for thread exit. It is a slightly thorny issue though, for a few reasons. For example, if .dlls get dynamically loaded/unloaded, threads can be created before they load -- no callback, or threads can be exited after they unload -- again, no callback. You only get callbacks when you are already loaded at the time of thread create/exit. You can also initialize on demand, assuming there is enough memory still. If the primary executable is not written in Modula-3, but has a static dependency on a Modula-3 .dll, then it works ok. - Jay > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 31 Mar 2009 09:45:22 +1100 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] per thread data? > > PS In general, I am loathe to make changes that complicate the code > based on performance assumptions that are only hypothetical. Better > to profile and see where the time is going before prematurely > "optimizing". > > On 31 Mar 2009, at 09:42, Tony Hosking wrote: > > > Yes, this is a tricky issue. At some point I seem to recall it > > being OK to have non-Modula-3 threads start running Modula-3 code, > > but I don't know for sure. I've never really liked the idea of > > having non-M3 threads. > > > > Are you using the existing handler maps and exception stack > > unwinding support for non-x86 NT? > > > > On 31 Mar 2009, at 09:15, Jay wrote: > > > >> > >> hm, thinking about this more... > >> What about threads not created by Modula-3 Fork() (or the first > >> thread)? > >> > >> It looks like exception handling had a chance of working on them > >> before. Now they'll crash upon entering functions > >> with try or raise or I presume lock. > >> > >> > >> 1) ok? > >> > >> > >> 2) do the heap alloc on demand? > >> But is that enough? Can it be initialized without further context? > >> Let's see..the circular list can be maintained without further > >> context. > >> handle := pthread_self, ok. stack can probably be figured out, though > >> that is probably just for gc and could be left alone for now, > >> continuing > >> to not work (or fixed)...getcontext at least on some platforms can > >> fill this in, or VirtualQuery/msomething (mmap family?)? > >> > >> > >> 3) put back the second thread local? > >> > >> > >> #2 has a chance of working better than before -- letting GC > >> work on threads not created by Modula-3 runtime, something > >> that has long bothered me...but I haven't done a complete analysis. > >> Or at least maybe keep it working as it was > >> For now there is somewhat of a regression, ie, when calling > >> Modula-3 code on threads not created from Modula-3. > >> Possibly the gc in this case was already dangerous? > >> Failing to find references on other stacks? > >> Or failing all allocations (should be easy to check but I have to > >> run..) > >> > >> > >> - Jay > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> ---------------------------------------- > >>> From: jay.krell at cornell.edu > >>> To: hosking at cs.purdue.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: RE: [M3devel] per thread data? > >>> Date: Mon, 30 Mar 2009 13:23:10 +0000 > >>> > >>> > >>> This was surprisingly difficult. > >>> > >>> > >>> InitHandlers is called much earlier than InitActivations. > >>> InitActivations does a heap allocation. > >>> InitHandlers did not. > >>> The types involved are not yet initialized at this point, or > >>> somesuch. > >>> You cannot NEW(Activation) in the first call to PushFrame. > >>> So, maybe, use a global for the first one, > >>> but then what happens is it gets reinitialized later by > >>> the module initializer -- which is perhaps another indictment > >>> of initializers..or maybe a special case in the depths of the > >>> system -- > >>> this module and anything it uses are subject to be called by > >>> compiler-generated calls -- they can be called before their > >>> initializers > >>> run.. seems to me the initialization could have happened > >>> "statically" > >>> like in C. > >>> > >>> > >>> Anyway, I should have this done shortly. > >>> Trick is to use a local value and assign it to a heap block > >>> allocated directly with calloc instead of RTAllocator. > >>> > >>> > >>> The result is maybe faster, maybe slower. > >>> Before, "try" cost pthread_getspecific and setspecific. > >>> Now it will just cost getspecific. > >>> But with another pointer deref and call to GetActivation > >>> with its on-demand initialization. > >>> > >>> > >>> Before, popframe only called setspecific. > >>> Now it will only call getspecific, plus the indirect > >>> and on-demand initialization. > >>> The on-demand seems bogus in pop, given that push already had to > >>> occur. > >>> So maybe that could be optimized. > >>> > >>> > >>> This stuff is highly optimized in C and C++ on NT.. > >>> NT/x86 has a special thread local just for exception handling, > >>> faster than all other thread locals. > >>> All non-x86 NT platforms have stack walkers -- no cost for "try", > >>> and then "throw" maps instruction pointer to data about how to > >>> to unwind the stack, using a little mini-assembly code. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ________________________________ > >>>> From: jay.krell at cornell.edu > >>>> To: hosking at cs.purdue.edu > >>>> Date: Thu, 19 Mar 2009 01:03:57 +0000 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] per thread data? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Thanks, I should get around to that "soon" then. > >>>> > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> ________________________________ > >>>> > >>>> From: hosking at cs.purdue.edu > >>>> To: jay.krell at cornell.edu > >>>> Date: Thu, 19 Mar 2009 10:14:59 +1100 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] per thread data? > >>>> > >>>> I have no problem putting the exception handler stack thread > >>>> local into the activation thread local. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On 18 Mar 2009, at 20:11, Jay wrote: > >>>> > >>>> > >>>> > >>>> I'm not looking at it right now, but doesn't seem rather piggy to > >>>> have two thread locals and data on the side? > >>>> > >>>> > >>>> I'm guessing the data on the side is needed because we need to be > >>>> able to enumerate our threads, to suspend them all? > >>>> > >>>> > >>>> I understand that having multiple thread locals optimizes their > >>>> use, but it seems greedy. > >>>> vs. a small heap allocation that combines them. > >>>> > >>>> Or in fact.. presumably there could just be one thread local that > >>>> is the thread pointer, and the handler link could be put at the > >>>> start, for architectures where zero offset is smaller/faster than > >>>> non-zero offset. > >>>> > >>>> > >>>> Another idea, of course, is to look into "__thread", > >>>> "__declspec(thread)". > >>>> > >>>> On Windows and probably all platforms they exist on, they are > >>>> nicely more efficient than pthread_get/setspecific, except on > >>>> Windows they don't really work acceptably prior to Vista -- they > >>>> only work in .exes and their static dependencies, not any .dll > >>>> you load after the process starts with LoadLibrary (dlopen). > >>>> > >>>> > >>>> Does "__thread" work well on most non-Windows platforms? > >>>> i.e. even if shared object is loaded with dlopen? > >>>> > >>>> > >>>> I could have sworn I saw code out there that was "adaptive". > >>>> It easily/efficiently checked if it was loaded with LoadLibrary > >>>> or not. > >>>> If so, it'd TlsGet/SetValue (pthread_get/setspecific). > >>>> If not, it'd use __declspec(thread) (__thread). > >>>> The check was based on if __tlsindex was not zero or somesuch. I > >>>> couldn't track it down though. > >>>> > >>>> > >>>> In either case, yes, I know, one of the thread locals at least is > >>>> gone on platforms that have stack walkers, e.g. Solaris, and > >>>> potentially NT, and maybe others. > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 31 02:27:01 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 00:27:01 +0000 Subject: [M3devel] per thread data? In-Reply-To: <21521BC5-BC0A-4852-A624-AF948D66C575@cs.purdue.edu> References: <21521BC5-BC0A-4852-A624-AF948D66C575@cs.purdue.edu> Message-ID: I understand, but pushframe/popframe seem so icky.. I like to try to keep things pretty ok as I go, but I realize your opinion is the more often stated one -- don't optimize prematurely. - Jay > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 31 Mar 2009 09:45:22 +1100 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] per thread data? > > PS In general, I am loathe to make changes that complicate the code > based on performance assumptions that are only hypothetical. Better > to profile and see where the time is going before prematurely > "optimizing". > > On 31 Mar 2009, at 09:42, Tony Hosking wrote: > > > Yes, this is a tricky issue. At some point I seem to recall it > > being OK to have non-Modula-3 threads start running Modula-3 code, > > but I don't know for sure. I've never really liked the idea of > > having non-M3 threads. > > > > Are you using the existing handler maps and exception stack > > unwinding support for non-x86 NT? > > > > On 31 Mar 2009, at 09:15, Jay wrote: > > > >> > >> hm, thinking about this more... > >> What about threads not created by Modula-3 Fork() (or the first > >> thread)? > >> > >> It looks like exception handling had a chance of working on them > >> before. Now they'll crash upon entering functions > >> with try or raise or I presume lock. > >> > >> > >> 1) ok? > >> > >> > >> 2) do the heap alloc on demand? > >> But is that enough? Can it be initialized without further context? > >> Let's see..the circular list can be maintained without further > >> context. > >> handle := pthread_self, ok. stack can probably be figured out, though > >> that is probably just for gc and could be left alone for now, > >> continuing > >> to not work (or fixed)...getcontext at least on some platforms can > >> fill this in, or VirtualQuery/msomething (mmap family?)? > >> > >> > >> 3) put back the second thread local? > >> > >> > >> #2 has a chance of working better than before -- letting GC > >> work on threads not created by Modula-3 runtime, something > >> that has long bothered me...but I haven't done a complete analysis. > >> Or at least maybe keep it working as it was > >> For now there is somewhat of a regression, ie, when calling > >> Modula-3 code on threads not created from Modula-3. > >> Possibly the gc in this case was already dangerous? > >> Failing to find references on other stacks? > >> Or failing all allocations (should be easy to check but I have to > >> run..) > >> > >> > >> - Jay > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> ---------------------------------------- > >>> From: jay.krell at cornell.edu > >>> To: hosking at cs.purdue.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: RE: [M3devel] per thread data? > >>> Date: Mon, 30 Mar 2009 13:23:10 +0000 > >>> > >>> > >>> This was surprisingly difficult. > >>> > >>> > >>> InitHandlers is called much earlier than InitActivations. > >>> InitActivations does a heap allocation. > >>> InitHandlers did not. > >>> The types involved are not yet initialized at this point, or > >>> somesuch. > >>> You cannot NEW(Activation) in the first call to PushFrame. > >>> So, maybe, use a global for the first one, > >>> but then what happens is it gets reinitialized later by > >>> the module initializer -- which is perhaps another indictment > >>> of initializers..or maybe a special case in the depths of the > >>> system -- > >>> this module and anything it uses are subject to be called by > >>> compiler-generated calls -- they can be called before their > >>> initializers > >>> run.. seems to me the initialization could have happened > >>> "statically" > >>> like in C. > >>> > >>> > >>> Anyway, I should have this done shortly. > >>> Trick is to use a local value and assign it to a heap block > >>> allocated directly with calloc instead of RTAllocator. > >>> > >>> > >>> The result is maybe faster, maybe slower. > >>> Before, "try" cost pthread_getspecific and setspecific. > >>> Now it will just cost getspecific. > >>> But with another pointer deref and call to GetActivation > >>> with its on-demand initialization. > >>> > >>> > >>> Before, popframe only called setspecific. > >>> Now it will only call getspecific, plus the indirect > >>> and on-demand initialization. > >>> The on-demand seems bogus in pop, given that push already had to > >>> occur. > >>> So maybe that could be optimized. > >>> > >>> > >>> This stuff is highly optimized in C and C++ on NT.. > >>> NT/x86 has a special thread local just for exception handling, > >>> faster than all other thread locals. > >>> All non-x86 NT platforms have stack walkers -- no cost for "try", > >>> and then "throw" maps instruction pointer to data about how to > >>> to unwind the stack, using a little mini-assembly code. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ________________________________ > >>>> From: jay.krell at cornell.edu > >>>> To: hosking at cs.purdue.edu > >>>> Date: Thu, 19 Mar 2009 01:03:57 +0000 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] per thread data? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Thanks, I should get around to that "soon" then. > >>>> > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> ________________________________ > >>>> > >>>> From: hosking at cs.purdue.edu > >>>> To: jay.krell at cornell.edu > >>>> Date: Thu, 19 Mar 2009 10:14:59 +1100 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] per thread data? > >>>> > >>>> I have no problem putting the exception handler stack thread > >>>> local into the activation thread local. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On 18 Mar 2009, at 20:11, Jay wrote: > >>>> > >>>> > >>>> > >>>> I'm not looking at it right now, but doesn't seem rather piggy to > >>>> have two thread locals and data on the side? > >>>> > >>>> > >>>> I'm guessing the data on the side is needed because we need to be > >>>> able to enumerate our threads, to suspend them all? > >>>> > >>>> > >>>> I understand that having multiple thread locals optimizes their > >>>> use, but it seems greedy. > >>>> vs. a small heap allocation that combines them. > >>>> > >>>> Or in fact.. presumably there could just be one thread local that > >>>> is the thread pointer, and the handler link could be put at the > >>>> start, for architectures where zero offset is smaller/faster than > >>>> non-zero offset. > >>>> > >>>> > >>>> Another idea, of course, is to look into "__thread", > >>>> "__declspec(thread)". > >>>> > >>>> On Windows and probably all platforms they exist on, they are > >>>> nicely more efficient than pthread_get/setspecific, except on > >>>> Windows they don't really work acceptably prior to Vista -- they > >>>> only work in .exes and their static dependencies, not any .dll > >>>> you load after the process starts with LoadLibrary (dlopen). > >>>> > >>>> > >>>> Does "__thread" work well on most non-Windows platforms? > >>>> i.e. even if shared object is loaded with dlopen? > >>>> > >>>> > >>>> I could have sworn I saw code out there that was "adaptive". > >>>> It easily/efficiently checked if it was loaded with LoadLibrary > >>>> or not. > >>>> If so, it'd TlsGet/SetValue (pthread_get/setspecific). > >>>> If not, it'd use __declspec(thread) (__thread). > >>>> The check was based on if __tlsindex was not zero or somesuch. I > >>>> couldn't track it down though. > >>>> > >>>> > >>>> In either case, yes, I know, one of the thread locals at least is > >>>> gone on platforms that have stack walkers, e.g. Solaris, and > >>>> potentially NT, and maybe others. > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carson at taltos.org Tue Mar 31 08:18:04 2009 From: carson at taltos.org (Carson Gaspar) Date: Mon, 30 Mar 2009 23:18:04 -0700 Subject: [M3devel] All snapshots are missing from the web site Message-ID: <49D1B59C.2040003@taltos.org> The cm3/snaps dir contains only .md5 and .cksum files, no actual tarballs. From carson at taltos.org Tue Mar 31 08:23:56 2009 From: carson at taltos.org (Carson Gaspar) Date: Mon, 30 Mar 2009 23:23:56 -0700 Subject: [M3devel] All snapshots are missing from the web site In-Reply-To: <49D1B59C.2040003@taltos.org> References: <49D1B59C.2040003@taltos.org> Message-ID: <49D1B6FC.50407@taltos.org> Carson Gaspar wrote: > The cm3/snaps dir contains only .md5 and .cksum files, no actual tarballs. Actually, _all_ tarballs appear to be missing and just give 404s. So cm3 is currently unobtanium :-( -- Carson From jay.krell at cornell.edu Tue Mar 31 09:06:21 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 07:06:21 +0000 Subject: [M3devel] All snapshots are missing from the web site In-Reply-To: <49D1B6FC.50407@taltos.org> References: <49D1B59C.2040003@taltos.org> <49D1B6FC.50407@taltos.org> Message-ID: http://modula3.elegosoft.com/cm3/ scroll to "current stable release 5.4.0" Those are all there. There are also still older releases evident in the file system and probably on the web. http://modula3.elegosoft.com/cm3/uploaded-archives are all there. - Jay > Date: Mon, 30 Mar 2009 23:23:56 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] All snapshots are missing from the web site > > Carson Gaspar wrote: > > The cm3/snaps dir contains only .md5 and .cksum files, no actual tarballs. > > Actually, _all_ tarballs appear to be missing and just give 404s. So cm3 > is currently unobtanium :-( > > -- > Carson > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 31 09:13:15 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 07:13:15 +0000 Subject: [M3devel] All snapshots are missing from the web site In-Reply-To: <49D1B6FC.50407@taltos.org> References: <49D1B59C.2040003@taltos.org> <49D1B6FC.50407@taltos.org> Message-ID: Speaking of unobtanium though, anyone interested in Itanium ports? I was able to at least get Linux running on IA64.. - Jay From: jay.krell at cornell.edu To: carson at taltos.org; m3devel at elegosoft.com Subject: RE: [M3devel] All snapshots are missing from the web site Date: Tue, 31 Mar 2009 07:06:21 +0000 http://modula3.elegosoft.com/cm3/ scroll to "current stable release 5.4.0" Those are all there. There are also still older releases evident in the file system and probably on the web. http://modula3.elegosoft.com/cm3/uploaded-archives are all there. - Jay > Date: Mon, 30 Mar 2009 23:23:56 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] All snapshots are missing from the web site > > Carson Gaspar wrote: > > The cm3/snaps dir contains only .md5 and .cksum files, no actual tarballs. > > Actually, _all_ tarballs appear to be missing and just give 404s. So cm3 > is currently unobtanium :-( > > -- > Carson > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 31 09:13:56 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 07:13:56 +0000 Subject: [M3devel] All snapshots are missing from the web site In-Reply-To: References: <49D1B59C.2040003@taltos.org> <49D1B6FC.50407@taltos.org> Message-ID: Bitten by frames..first URL is: http://modula3.elegosoft.com/cm3/download.html - Jay From: jay.krell at cornell.edu To: carson at taltos.org; m3devel at elegosoft.com Date: Tue, 31 Mar 2009 07:06:21 +0000 Subject: Re: [M3devel] All snapshots are missing from the web site http://modula3.elegosoft.com/cm3/ scroll to "current stable release 5.4.0" Those are all there. There are also still older releases evident in the file system and probably on the web. http://modula3.elegosoft.com/cm3/uploaded-archives are all there. - Jay > Date: Mon, 30 Mar 2009 23:23:56 -0700 > From: carson at taltos.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] All snapshots are missing from the web site > > Carson Gaspar wrote: > > The cm3/snaps dir contains only .md5 and .cksum files, no actual tarballs. > > Actually, _all_ tarballs appear to be missing and just give 404s. So cm3 > is currently unobtanium :-( > > -- > Carson > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 31 10:17:08 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 08:17:08 +0000 Subject: [M3devel] per thread data? In-Reply-To: References: <21521BC5-BC0A-4852-A624-AF948D66C575@cs.purdue.edu> Message-ID: [I don't see it below, but you mentioned not liking the use of calloc.] It doesn't have to use calloc. It can be statically allocated as an array [1..BYTESIZE(ActivationRecord)] of CHAR. I didn't do that because I was confused and thought there'd be overhead, but that's just for open arrays probably, not fixed size arrays. This is just for the first thread/activation. Subsequent ones are unchanged, using NEW. If there was a way to suppress the initializer, then a regular static allocation could be used. I went around removing the initializer for Activation and its contituent types (RTHeapRep.ThreadState) but then thought of what I have. Another fix might be to reorder InitRuntime to get the relevant modules/types initialized earlier. I didn't look into that. As well, perhaps, altering the data structure used during startup to be initially statically allocated, if they aren't already, and large enough to not need heap allocation for "long enough". That is, if you use NEW here, there are two problems. - the infinite recursion on pushframe That is fixed by pushing the RAISE into a separate function. Currently the transform like that in RTAllocator is only for "perf", but depending on the final form of ThreadPThread, it could be for correctness. (I need to fix Win32 too.) - the fact that the typedefn isn't complete yet That's what I didn't look into adequately and could maybe come up with a reasonable fix for. You can see I changed the code so the result of an incomplete typedefn is clearer in the debugger. Though again, a static allocation of an ARRAY 1..size of CHAR should suffice just fine, perhaps being better than it was and better than it is. I still use calloc for the conditions/mutexes though. The point there was to remove the open array overhead. And to, like, to keep things simpler for myself. I think I was using the address of the array instead of its first element, unaware of the difference. With calloc that layer isn't there. But this can use NEW if you want, though again, it'll waste space for the open array size. These are all untraced allocations anyway, so I didn't think there's any great advantage to RTAllocator. I do realize now that it is what knows how to run type initializers. That is a nice feature. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 31 Mar 2009 00:27:01 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] per thread data? I understand, but pushframe/popframe seem so icky.. I like to try to keep things pretty ok as I go, but I realize your opinion is the more often stated one -- don't optimize prematurely. - Jay > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 31 Mar 2009 09:45:22 +1100 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] per thread data? > > PS In general, I am loathe to make changes that complicate the code > based on performance assumptions that are only hypothetical. Better > to profile and see where the time is going before prematurely > "optimizing". > > On 31 Mar 2009, at 09:42, Tony Hosking wrote: > > > Yes, this is a tricky issue. At some point I seem to recall it > > being OK to have non-Modula-3 threads start running Modula-3 code, > > but I don't know for sure. I've never really liked the idea of > > having non-M3 threads. > > > > Are you using the existing handler maps and exception stack > > unwinding support for non-x86 NT? > > > > On 31 Mar 2009, at 09:15, Jay wrote: > > > >> > >> hm, thinking about this more... > >> What about threads not created by Modula-3 Fork() (or the first > >> thread)? > >> > >> It looks like exception handling had a chance of working on them > >> before. Now they'll crash upon entering functions > >> with try or raise or I presume lock. > >> > >> > >> 1) ok? > >> > >> > >> 2) do the heap alloc on demand? > >> But is that enough? Can it be initialized without further context? > >> Let's see..the circular list can be maintained without further > >> context. > >> handle := pthread_self, ok. stack can probably be figured out, though > >> that is probably just for gc and could be left alone for now, > >> continuing > >> to not work (or fixed)...getcontext at least on some platforms can > >> fill this in, or VirtualQuery/msomething (mmap family?)? > >> > >> > >> 3) put back the second thread local? > >> > >> > >> #2 has a chance of working better than before -- letting GC > >> work on threads not created by Modula-3 runtime, something > >> that has long bothered me...but I haven't done a complete analysis. > >> Or at least maybe keep it working as it was > >> For now there is somewhat of a regression, ie, when calling > >> Modula-3 code on threads not created from Modula-3. > >> Possibly the gc in this case was already dangerous? > >> Failing to find references on other stacks? > >> Or failing all allocations (should be easy to check but I have to > >> run..) > >> > >> > >> - Jay > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> ---------------------------------------- > >>> From: jay.krell at cornell.edu > >>> To: hosking at cs.purdue.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: RE: [M3devel] per thread data? > >>> Date: Mon, 30 Mar 2009 13:23:10 +0000 > >>> > >>> > >>> This was surprisingly difficult. > >>> > >>> > >>> InitHandlers is called much earlier than InitActivations. > >>> InitActivations does a heap allocation. > >>> InitHandlers did not. > >>> The types involved are not yet initialized at this point, or > >>> somesuch. > >>> You cannot NEW(Activation) in the first call to PushFrame. > >>> So, maybe, use a global for the first one, > >>> but then what happens is it gets reinitialized later by > >>> the module initializer -- which is perhaps another indictment > >>> of initializers..or maybe a special case in the depths of the > >>> system -- > >>> this module and anything it uses are subject to be called by > >>> compiler-generated calls -- they can be called before their > >>> initializers > >>> run.. seems to me the initialization could have happened > >>> "statically" > >>> like in C. > >>> > >>> > >>> Anyway, I should have this done shortly. > >>> Trick is to use a local value and assign it to a heap block > >>> allocated directly with calloc instead of RTAllocator. > >>> > >>> > >>> The result is maybe faster, maybe slower. > >>> Before, "try" cost pthread_getspecific and setspecific. > >>> Now it will just cost getspecific. > >>> But with another pointer deref and call to GetActivation > >>> with its on-demand initialization. > >>> > >>> > >>> Before, popframe only called setspecific. > >>> Now it will only call getspecific, plus the indirect > >>> and on-demand initialization. > >>> The on-demand seems bogus in pop, given that push already had to > >>> occur. > >>> So maybe that could be optimized. > >>> > >>> > >>> This stuff is highly optimized in C and C++ on NT.. > >>> NT/x86 has a special thread local just for exception handling, > >>> faster than all other thread locals. > >>> All non-x86 NT platforms have stack walkers -- no cost for "try", > >>> and then "throw" maps instruction pointer to data about how to > >>> to unwind the stack, using a little mini-assembly code. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ________________________________ > >>>> From: jay.krell at cornell.edu > >>>> To: hosking at cs.purdue.edu > >>>> Date: Thu, 19 Mar 2009 01:03:57 +0000 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] per thread data? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Thanks, I should get around to that "soon" then. > >>>> > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> ________________________________ > >>>> > >>>> From: hosking at cs.purdue.edu > >>>> To: jay.krell at cornell.edu > >>>> Date: Thu, 19 Mar 2009 10:14:59 +1100 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] per thread data? > >>>> > >>>> I have no problem putting the exception handler stack thread > >>>> local into the activation thread local. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On 18 Mar 2009, at 20:11, Jay wrote: > >>>> > >>>> > >>>> > >>>> I'm not looking at it right now, but doesn't seem rather piggy to > >>>> have two thread locals and data on the side? > >>>> > >>>> > >>>> I'm guessing the data on the side is needed because we need to be > >>>> able to enumerate our threads, to suspend them all? > >>>> > >>>> > >>>> I understand that having multiple thread locals optimizes their > >>>> use, but it seems greedy. > >>>> vs. a small heap allocation that combines them. > >>>> > >>>> Or in fact.. presumably there could just be one thread local that > >>>> is the thread pointer, and the handler link could be put at the > >>>> start, for architectures where zero offset is smaller/faster than > >>>> non-zero offset. > >>>> > >>>> > >>>> Another idea, of course, is to look into "__thread", > >>>> "__declspec(thread)". > >>>> > >>>> On Windows and probably all platforms they exist on, they are > >>>> nicely more efficient than pthread_get/setspecific, except on > >>>> Windows they don't really work acceptably prior to Vista -- they > >>>> only work in .exes and their static dependencies, not any .dll > >>>> you load after the process starts with LoadLibrary (dlopen). > >>>> > >>>> > >>>> Does "__thread" work well on most non-Windows platforms? > >>>> i.e. even if shared object is loaded with dlopen? > >>>> > >>>> > >>>> I could have sworn I saw code out there that was "adaptive". > >>>> It easily/efficiently checked if it was loaded with LoadLibrary > >>>> or not. > >>>> If so, it'd TlsGet/SetValue (pthread_get/setspecific). > >>>> If not, it'd use __declspec(thread) (__thread). > >>>> The check was based on if __tlsindex was not zero or somesuch. I > >>>> couldn't track it down though. > >>>> > >>>> > >>>> In either case, yes, I know, one of the thread locals at least is > >>>> gone on platforms that have stack walkers, e.g. Solaris, and > >>>> potentially NT, and maybe others. > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Mar 31 12:52:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Mar 2009 21:52:29 +1100 Subject: [M3devel] Fwd: Output from "cron" command References: <200903311030.n2VAUHqY006834@niagara.cs.purdue.edu> Message-ID: <7C7074F3-B9BF-4C17-8BD0-8A83833598C5@cs.purdue.edu> Tinderbox still broken? Begin forwarded message: > From: Tony Hosking > Date: 31 March 2009 21:30:17 GMT+11:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-03-31-10-30-04 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090331-063006-tGai9m/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.03.31 06:30:06 -- checkout in progress. > Content-type: text/html > > > [Tue Mar 31 12:30:08 2009] processmail_builds.cgi: Security Error. > Must not run this program using an effective user id which is > different than the tinderbox user id. id: 10006 id must be 33 > > > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090331-063006-tGai9m ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-03-31-10-30-12 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090331-063014-VOaOkn/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.03.31 06:30:14 -- checkout in progress. > Content-type: text/html > > > [Tue Mar 31 12:30:16 2009] processmail_builds.cgi: Security Error. > Must not run this program using an effective user id which is > different than the tinderbox user id. id: 10006 id must be 33 > > > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090331-063014-VOaOkn ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Mar 31 13:39:10 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 31 Mar 2009 13:39:10 +0200 Subject: [M3devel] m3 CVS? In-Reply-To: <20090330131918.GA6921@topoi.pooq.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> Message-ID: <20090331133910.flci659jockgo04c@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > Is CVS back up yet? Completely? I've been delaying trying the > monotone conversion because it would be nice to have only one set > of problems to look into. CVS is up and no history should be lost, but tinderbox is still not working and several archives are missing. Michael is working on it (but he's got some other tasks, too). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Tue Mar 31 15:56:10 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 31 Mar 2009 09:56:10 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: <20090331133910.flci659jockgo04c@mail.elegosoft.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> Message-ID: <20090331135610.GA9539@topoi.pooq.com> On Tue, Mar 31, 2009 at 01:39:10PM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > > >Is CVS back up yet? Completely? I've been delaying trying the > >monotone conversion because it would be nice to have only one set > >of problems to look into. > > CVS is up and no history should be lost, but tinderbox is still not > working and several archives are missing. Michael is working on it > (but he's got some other tasks, too). So the current source is available, but not the tools to investigate their status on-line. And the other archives? What are they? Are they more source code? Should they be subject to revision control too? Are they ancient prehistory that should be grafted into the revision tree except that it may not be technically feasible? Ah. I have too many questions. By the way, rumours are that monotone's cvs pull command is quite demanding on the cvs server, but that sync operation isn't bad at all after that. Getting really old versions of files requires CVS to chain back through a lot of reverse differences. And I don't know if it caches any of that in case it is asked to cough up another really old version. If there are any scheduling considerations I'd like to hear them. I don't know if I'll flatten your system, but if I do there are probably better and worse times to do it. (I may saturate ny DSL link first, but you never know until you try it.) By the way, what's the total size of Modula 3's CVS archive? -- hendrik From wagner at elegosoft.com Tue Mar 31 16:19:08 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 31 Mar 2009 16:19:08 +0200 Subject: [M3devel] m3 CVS? In-Reply-To: <20090331135610.GA9539@topoi.pooq.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> Message-ID: <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Tue, Mar 31, 2009 at 01:39:10PM +0200, Olaf Wagner wrote: >> Quoting hendrik at topoi.pooq.com: >> >> >Is CVS back up yet? Completely? I've been delaying trying the >> >monotone conversion because it would be nice to have only one set >> >of problems to look into. >> >> CVS is up and no history should be lost, but tinderbox is still not >> working and several archives are missing. Michael is working on it >> (but he's got some other tasks, too). > > So the current source is available, but not the tools to investigate > their status on-line. And the other archives? What are they? Are they > more source code? Should they be subject to revision control too? Are > they ancient prehistory that should be grafted into the revision tree > except that it may not be technically feasible? Mostly all the old installation archives and snapshots are still missing. I'm not sure what's the status of the re-installation of tinderbox. > Ah. I have too many questions. > > By the way, rumours are that monotone's cvs pull command is quite > demanding on the cvs server, but that sync operation isn't bad at all > after that. Getting really old versions of files requires CVS to chain > back through a lot of reverse differences. And I don't know if it > caches any of that in case it is asked to cough up another really old > version. > > If there are any scheduling considerations I'd like to hear them. I > don't know if I'll flatten your system, but if I do there are probably > better and worse times to do it. (I may saturate ny DSL link first, but > you never know until you try it.) > > By the way, what's the total size of Modula 3's CVS archive? I've got no access from here (can only check later tonight); please ask Michael Anderson directly for administrative topics. Olaf PS: I don't think you can bring the server down a one external CVS client; the syncing will just take a long time. Unless lots of parallel requests are started... -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Tue Mar 31 16:42:52 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 31 Mar 2009 10:42:52 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> References: <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> Message-ID: <20090331144252.GA9624@topoi.pooq.com> On Tue, Mar 31, 2009 at 04:19:08PM +0200, Olaf Wagner wrote: > > > >So the current source is available, but not the tools to investigate > >their status on-line. And the other archives? What are they? Are they > >more source code? Should they be subject to revision control too? Are > >they ancient prehistory that should be grafted into the revision tree > >except that it may not be technically feasible? > > Mostly all the old installation archives and snapshots are still missing. > I'm not sure what's the status of the re-installation of tinderbox. So those are things that were once generated form CVS. Not source code. I won't need them then. Speaking of ancient history -- Are cm3 and pm3 both in one CVS so that they share history? Or are they in separate CVS's? > client; the syncing will just take a long time. Unless lots of parallel > requests are started... That's good. So it'll just take a long time. That's OK. -- hendrik > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From hendrik at topoi.pooq.com Tue Mar 31 16:51:27 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 31 Mar 2009 10:51:27 -0400 Subject: [M3devel] small design problem in ButtonVBT? Message-ID: <20090331145127.GB9624@topoi.pooq.com> The BottonVBT contains an action, which is a procedure rather than a method. b This makes it awkward to subclass ButtonVBT becaue the action will still expect its first parameter to be a ButtonVBT instead of belonging to the subclass, and an explicit downcast of some sort will be needed to acess the subclass's members. The Trestle manual says this was a deliberate decision: : The action procedure is a field rather than a method in order to allow : buttons with different action procedures to share their method suites. I, however, find it massively inconvenient because it mans I have to resort to downcasting or the very kludgey VBT.GetProp to access what should be just there. I'd rather the action procedure was a method. But it should be possible to have the best of both worlds. Have an action2 (better name wanted here) method that is available for overriding, and by default calls the procedure in the existing action. field. That action2 method wounl then be called by Trestle wherever action is now called. Does anyone see problems with this? -- hendrik From wagner at elegosoft.com Tue Mar 31 17:35:42 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 31 Mar 2009 17:35:42 +0200 Subject: [M3devel] m3 CVS? In-Reply-To: <20090331144252.GA9624@topoi.pooq.com> References: <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> Message-ID: <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > Speaking of ancient history -- Are cm3 and pm3 both in one CVS so that > they share history? Or are they in separate CVS's? CM3 and PM3 are two separate repositories. SRC never used CVS for M3 version control (don't exactly know how they did managed the sources). PM3 was created by Michel Dagenais as an open source continuation of SRC M3, while CM3 started as a commercial product and was later open sourced. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Tue Mar 31 20:42:06 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 31 Mar 2009 11:42:06 -0700 Subject: [M3devel] Help finding CM3 compiler for Linux? Message-ID: <200903311842.n2VIg6LS046075@camembert.async.caltech.edu> Hello everyone, This is, for me, a most unfortunate time for the CM3 servers to have crashed. I'm teaching a class using Modula-3, and we need a compiler... here's the uname of the system I'm trying to use: Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux The most recent archives I have for Linux are: cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz And they don't seem to work on this system: I can compile a program but when I try to run it, it says "Segmentation fault". Can anyone help? (My understanding is that I need 5.5.1 or later...) Mika From martinbishop at bellsouth.net Tue Mar 31 22:43:41 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Tue, 31 Mar 2009 15:43:41 -0500 Subject: [M3devel] Help finding CM3 compiler for Linux? In-Reply-To: <200903311842.n2VIg6LS046075@camembert.async.caltech.edu> References: <200903311842.n2VIg6LS046075@camembert.async.caltech.edu> Message-ID: <49D2807D.7010100@bellsouth.net> Not sure if this helps, but on my linux system: Critical Mass Modula-3 version d5.7.0 last updated: 2008-03-16 compiled: 2008-08-14 00:56:14 configuration: /usr/local/cm3/bin/cm3.cfg Linux thinkpad 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux I don't have the cm3 tarball, but I do have the sources in cm3/ still. Mika Nystrom wrote: > Hello everyone, > > This is, for me, a most unfortunate time for the CM3 servers to > have crashed. I'm teaching a class using Modula-3, and we need a > compiler... here's the uname of the system I'm trying to use: > > Linux lara 2.6.24ugcs1 #4 SMP Mon Feb 11 10:53:03 PST 2008 i686 GNU/Linux > > The most recent archives I have for Linux are: > > cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz cm3-src-all-5.4.0.tgz > > And they don't seem to work on this system: I can compile a program > but when I try to run it, it says "Segmentation fault". Can anyone > help? (My understanding is that I need 5.5.1 or later...) > > Mika > From hosking at cs.purdue.edu Tue Mar 31 23:58:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 1 Apr 2009 08:58:02 +1100 Subject: [M3devel] m3 CVS? In-Reply-To: <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> References: <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> <20090330131918.GA6921@topoi.pooq.com> <20090331133910.flci659jockgo04c@mail.elegosoft.com> <20090331135610.GA9539@topoi.pooq.com> <20090331161908.3pferzf9c08oso40@mail.elegosoft.com> <20090331144252.GA9624@topoi.pooq.com> <20090331173542.60xixsbl4w4kcsgs@mail.elegosoft.com> Message-ID: <47E57322-28FD-4C9E-B1FE-12761C6F32AB@cs.purdue.edu> Both PM3 and CM3 forked from SRC M3. On 1 Apr 2009, at 02:35, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> Speaking of ancient history -- Are cm3 and pm3 both in one CVS so >> that >> they share history? Or are they in separate CVS's? > > CM3 and PM3 are two separate repositories. SRC never used CVS for M3 > version control (don't exactly know how they did managed the sources). > PM3 was created by Michel Dagenais as an open source continuation of > SRC M3, while CM3 started as a commercial product and was later open > sourced. > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rodney.bates at wichita.edu Sun Mar 1 18:30:41 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 01 Mar 2009 11:30:41 -0600 Subject: [M3devel] aclocal.m4 Message-ID: <49AAC641.8050205@wichita.edu> What is the story on m3-sys/m3cc/gcc/mpfr/aclocal.m4? The cvs repository has a copy that is always empty and I always have a local copy with a lot of stuff in it, giving a lot of cvs diff output that makes it look like I made local changes. It this file always generated during the build process? Should it be removed from the repository? Rodney Bates From jay.krell at cornell.edu Sun Mar 1 20:31:56 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 1 Mar 2009 19:31:56 +0000 Subject: [M3devel] aclocal.m4 In-Reply-To: <49AAC641.8050205@wichita.edu> References: <49AAC641.8050205@wichita.edu> Message-ID: Probably you have auto* tools installed, and the timestamps are messed up somewhere, such that more stuff is being built. Similarly I used to always see the documentation get rebuilt in my builds, really fouling up cvs diff. I fixed that by having m3makefile say stuff like MAKEINFO=: (colon is an empty command). I never tracked down why the build steps were running which generally aren't supposed to, unless you edit files that "we" don't edit. Tangentially: gmp and mpfr are a significant fraction of building gcc. I wonder if we can't be smarter here..if /usr/local/lib/libgmp.a exists, tell configure not to build it, or somesuch. Back on topic. Most of you probably know this but just in case: In many projects in the wider Unixish/GNUish world, there are a lot of a certain class of checked in "derived" files. "Derived" being the Modula-3 term for "built" or "machine generated" or "compiler output", etc. "Derived" files are usually "binary", like .o files, but they can also be text files. For example, when you run configure it produces Makefile and config.h. The configure sh program is actually a "derived" file, from something like configure.ac. Makefile (not usually checked in) is derived from Makefile.in (usually checked in), which is often derived from Makefile.am. Now, further afield..from there are documentation-related checked in files, and the file you point out Rodney is probably generated. Another good example is people often checkin the output of lex or yacc, so that build who only have a C compiler/linker but not lex or yacc can build the software. Generally in source control the checked in derived files have a newer timestamp than their source files, so a build will "naturally" not try to build them. Often these files have "additional build dependencies" such as needing perl installed, that the project does not wish to foist upon everyone. So that's the background possibly all redundant. The questions boil down to: - What is up with the timestamps? I don't mean just on your machine Rodney. I generally don't have a full auto* toolset installed. I haven't figured out how is supposed to have a variety of versions installed /and/ have the Makefile pick the right one. I can all them all to separate -prefix, but that doesn't solve it. So, that implies why I don't see this exact case, but as I said, I used to see with this a bunch of other files. - You see it for other files too? - Other folks see it? - Is there a simple hack like I did for makeinfo that can quash it? I'll see. I guess I can just install latest autotools and see what happens. - Jay > Date: Sun, 1 Mar 2009 11:30:41 -0600 > From: rodney.bates at wichita.edu > To: m3devel at elegosoft.com > Subject: [M3devel] aclocal.m4 > > What is the story on m3-sys/m3cc/gcc/mpfr/aclocal.m4? The cvs repository has a > copy that is always empty and I always have a local copy with a lot of stuff > in it, giving a lot of cvs diff output that makes it look like I made local > changes. It this file always generated during the build process? Should it > be removed from the repository? > > Rodney Bates -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 2 14:30:22 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Mar 2009 13:30:22 +0000 Subject: [M3devel] aclocal.m4 In-Reply-To: <49AAC641.8050205@wichita.edu> References: <49AAC641.8050205@wichita.edu> Message-ID: This appears to be fixed in mpfr 2.3.2. We have 2.3.0. I didn't look at 2.3.1 or track down when the fix came in. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rodney.bates at wichita.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] aclocal.m4 > Date: Mon, 2 Mar 2009 13:25:38 +0000 > > > "This stuff" is mostly disabled by lack of -enable-maintainer-mode > on the configure command line. > In most of the Makefiles there is @MAINT@ which by default evaluates to a comment. > Mpfr doesn't do it this way. > Maybe due to different versions of auto tools? > That's what I know so far.. > > - Jay > > ________________________________ >> From: jay.krell at cornell.edu >> To: rodney.bates at wichita.edu; m3devel at elegosoft.com >> Subject: RE: [M3devel] aclocal.m4 >> Date: Sun, 1 Mar 2009 19:31:56 +0000 >> >> >> >> >> >> >> >> >> Probably you have auto* tools installed, and the timestamps are messed up somewhere, such that more stuff is being built. Similarly I used to always see the documentation get rebuilt in my builds, really fouling up cvs diff. I fixed that by having m3makefile say stuff like MAKEINFO=: (colon is an empty command). I never tracked down why the build steps were running which generally aren't supposed to, unless you edit files that "we" don't edit. >> >> >> >> >> >> Tangentially: gmp and mpfr are a significant fraction of building gcc. I wonder if we can't be smarter here..if /usr/local/lib/libgmp.a exists, tell configure not to build it, or somesuch. >> >> >> >> Back on topic. Most of you probably know this but just in case: >> >> In many projects in the wider Unixish/GNUish world, there are a lot of a certain class of checked in "derived" files. "Derived" being the Modula-3 term for "built" or "machine generated" or "compiler output", etc. "Derived" files are usually "binary", like .o files, but they can also be text files. For example, when you run configure it produces Makefile and config.h. >> >> The configure sh program is actually a "derived" file, from something like configure.ac. >> >> Makefile (not usually checked in) is derived from Makefile.in (usually checked in), which is often derived from Makefile.am. >> >> Now, further afield..from there are documentation-related checked in files, and the file you point out Rodney is probably generated. >> >> Another good example is people often checkin the output of lex or yacc, so that build who only have a C compiler/linker but not lex or yacc can build the software. >> >> >> >> Generally in source control the checked in derived files have a newer timestamp than their source files, so a build will "naturally" not try to build them. >> >> Often these files have "additional build dependencies" such as needing perl installed, that the project does not wish to foist upon everyone. >> >> >> >> So that's the background possibly all redundant. >> >> >> >> The questions boil down to: >> >> - What is up with the timestamps? >> >> I don't mean just on your machine Rodney. I generally don't have a full auto* toolset installed. I haven't figured out how is supposed to have a variety of versions installed /and/ have the Makefile pick the right one. I can all them all to separate -prefix, but that doesn't solve it. >> >> So, that implies why I don't see this exact case, but as I said, I used to see with this a bunch of other files. >> >> >> >> - You see it for other files too? >> >> >> >> - Other folks see it? >> >> >> >> - Is there a simple hack like I did for makeinfo that can quash it? I'll see. >> >> >> >> I guess I can just install latest autotools and see what happens. >> >> >> >> >> >> - Jay >> >> >> >>> Date: Sun, 1 Mar 2009 11:30:41 -0600 >>> From: rodney.bates at wichita.edu >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] aclocal.m4 >>> >>> What is the story on m3-sys/m3cc/gcc/mpfr/aclocal.m4? The cvs repository has a >>> copy that is always empty and I always have a local copy with a lot of stuff >>> in it, giving a lot of cvs diff output that makes it look like I made local >>> changes. It this file always generated during the build process? Should it >>> be removed from the repository? >>> >>> Rodney Bates From jay.krell at cornell.edu Mon Mar 2 14:25:38 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Mar 2009 13:25:38 +0000 Subject: [M3devel] aclocal.m4 In-Reply-To: <49AAC641.8050205@wichita.edu> References: <49AAC641.8050205@wichita.edu> Message-ID: "This stuff" is mostly disabled by lack of -enable-maintainer-mode on the configure command line. In most of the Makefiles there is @MAINT@ which by default evaluates to a comment. Mpfr doesn't do it this way. Maybe due to different versions of auto tools? That's what I know so far.. - Jay ________________________________ > From: jay.krell at cornell.edu > To: rodney.bates at wichita.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] aclocal.m4 > Date: Sun, 1 Mar 2009 19:31:56 +0000 > > > > > > > > > Probably you have auto* tools installed, and the timestamps are messed up somewhere, such that more stuff is being built. Similarly I used to always see the documentation get rebuilt in my builds, really fouling up cvs diff. I fixed that by having m3makefile say stuff like MAKEINFO=: (colon is an empty command). I never tracked down why the build steps were running which generally aren't supposed to, unless you edit files that "we" don't edit. > > > > > > Tangentially: gmp and mpfr are a significant fraction of building gcc. I wonder if we can't be smarter here..if /usr/local/lib/libgmp.a exists, tell configure not to build it, or somesuch. > > > > Back on topic. Most of you probably know this but just in case: > > In many projects in the wider Unixish/GNUish world, there are a lot of a certain class of checked in "derived" files. "Derived" being the Modula-3 term for "built" or "machine generated" or "compiler output", etc. "Derived" files are usually "binary", like .o files, but they can also be text files. For example, when you run configure it produces Makefile and config.h. > > The configure sh program is actually a "derived" file, from something like configure.ac. > > Makefile (not usually checked in) is derived from Makefile.in (usually checked in), which is often derived from Makefile.am. > > Now, further afield..from there are documentation-related checked in files, and the file you point out Rodney is probably generated. > > Another good example is people often checkin the output of lex or yacc, so that build who only have a C compiler/linker but not lex or yacc can build the software. > > > > Generally in source control the checked in derived files have a newer timestamp than their source files, so a build will "naturally" not try to build them. > > Often these files have "additional build dependencies" such as needing perl installed, that the project does not wish to foist upon everyone. > > > > So that's the background possibly all redundant. > > > > The questions boil down to: > > - What is up with the timestamps? > > I don't mean just on your machine Rodney. I generally don't have a full auto* toolset installed. I haven't figured out how is supposed to have a variety of versions installed /and/ have the Makefile pick the right one. I can all them all to separate -prefix, but that doesn't solve it. > > So, that implies why I don't see this exact case, but as I said, I used to see with this a bunch of other files. > > > > - You see it for other files too? > > > > - Other folks see it? > > > > - Is there a simple hack like I did for makeinfo that can quash it? I'll see. > > > > I guess I can just install latest autotools and see what happens. > > > > > > - Jay > > > >> Date: Sun, 1 Mar 2009 11:30:41 -0600 >> From: rodney.bates at wichita.edu >> To: m3devel at elegosoft.com >> Subject: [M3devel] aclocal.m4 >> >> What is the story on m3-sys/m3cc/gcc/mpfr/aclocal.m4? The cvs repository has a >> copy that is always empty and I always have a local copy with a lot of stuff >> in it, giving a lot of cvs diff output that makes it look like I made local >> changes. It this file always generated during the build process? Should it >> be removed from the repository? >> >> Rodney Bates From jay.krell at cornell.edu Mon Mar 2 16:48:44 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Mar 2009 15:48:44 +0000 Subject: [M3devel] PA32_HPUX available Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-PA32_HPUX-1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-PA32_HPUX-1.tar.lzma Here is a current build of PA32_HPUX, including all of "std". The system builds itself and various gui apps startup. Pthreads are used. User threads are not implemented. The man page for get/set/make/swapcontext says they won't necessarily stay compatible. Dynamic linking is supported and used. This should match the current source tree, except my change to cm3cfg.common isn't reflected here -- the backend is not itself optimized. It requires the GNU C compiler and assembler -- gcc and gas. It does not require, and probably won't work with, the GNU linker. e.g. extract binutils and then rm -rf intl gold ld elfcpp binutils, leaving just like libiberaty, bfd, opcodes, gas, and then build it, or use -disable-x to not build those directories, or build it all, but instead of install, just copy gas, it's just one file. It might require getting up to date patches esp. for ld. I was not able to build libstdc++ without patching ld, but building libstdc++ is not necessary for Modula-3. It is a C++ thing. I'm using HP-UX 11iv1 aka 11.11 (this is two versions out of date, there is v2 and v3). The cm3.cfg file in the archive delegates to $CM3_ROOT/m3-sys/cminstall/src/config-no-install/PA32_HPUX. and that file is somewhat specific to my configuration. I can see about making it just use $PATH. Problem is, on this sytem gcc doesn't support multilibs/-m32/-m64, so you really need two separate "prefixes" and paths to work with 32bit and 64bit targets, so I use /usr/local/32 and /usr/local/64. It is possible to bootstrap to a good working system from the bundled compiler, but you have to go through gcc 3.3.6 first. There are my full paths in these binaries: /cm3/lib/libm3core.sl.5 and such but you can set SHLIB_PATH to a colon delimited directory that includes where you install to. I haven't figured out yet how to omit the paths. Perhaps we should use "$ORIGIN/../lib"? Also, the stock HP-UX system does contain X or OpenGL headers/libs, but they are a free download. Search the web. At least the X headers/libs come with the unbundled compiler. mentor does not work. It says: "*** Cannot create TCP port". If $DISPLAY is not set correctly, the errors are not consistent. - Jay From jay.krell at cornell.edu Mon Mar 2 21:37:48 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Mar 2009 20:37:48 +0000 Subject: [M3devel] -g other than -gstabs? Message-ID: Has anyone looked into why -g, -ggdb, -gwhateverelse tend to crash m3cgc1? While -gstabs and -gstabs+ work ok? -gstabs isn't supported on hppa64-hpux. I'll try to look into this, if nobody else has the answer. The double thing isn't fully resolved either, as hppa64-hpux hangs in TimePosix too. I'll patch parse.c inappropriately locally for now and look into it more "later". (Even without -g the stack is shown, so I can see TimePosix hang.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Mar 2 23:13:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 02 Mar 2009 23:13:44 +0100 Subject: [M3devel] cm3 tinderbox status Message-ID: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> Being back in town, I find that over the weekend almost all of the m3 tests in tinderbox failed. What's going on there? I don't want to sound like Kassandra, especially since I'm not contributing actively myself currently, but I'd really like all committers to keep an eye on all the regression tests and fix things as soon as they fall off in quality. I've got the slight feeling that the overall quality of the M3 code base does not really increase currently. Please, let's all try to keep everything working as good as possible. If you check in something, monitor the effects in the various tinderbox regressions tests: http://tinderbox.elegosoft.com/tinderbox/cm3/status.html http://www.opencm3.net/logs/package-status.html http://www.opencm3.net/m3tests/index.html Thanks in advance for your cooperation and help, Olaf PS: I also have the strong feeling that an official release is overdue. We should stop developing features and focus on building stable new distribution archives for a while. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Mar 2 23:52:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Mar 2009 09:52:50 +1100 Subject: [M3devel] cm3 tinderbox status In-Reply-To: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> References: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> Message-ID: Hear hear. Things have been broken for days now... On 3 Mar 2009, at 09:13, Olaf Wagner wrote: > Being back in town, I find that over the weekend almost all of the > m3 tests in tinderbox failed. What's going on there? > > I don't want to sound like Kassandra, especially since I'm not > contributing actively myself currently, but I'd really like > all committers to keep an eye on all the regression tests and > fix things as soon as they fall off in quality. I've got the > slight feeling that the overall quality of the M3 code base > does not really increase currently. > > Please, let's all try to keep everything working as good as possible. > If you check in something, monitor the effects in the various > tinderbox regressions tests: > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > http://www.opencm3.net/logs/package-status.html > http://www.opencm3.net/m3tests/index.html > > Thanks in advance for your cooperation and help, > > Olaf > > PS: I also have the strong feeling that an official release is > overdue. We should stop developing features and focus on building > stable new distribution archives for a while. > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jay.krell at cornell.edu Tue Mar 3 00:56:46 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 2 Mar 2009 23:56:46 +0000 Subject: [M3devel] cm3 tinderbox status In-Reply-To: References: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> Message-ID: I checked the status page, but there was no red. I see the large numbers now. Lots of +"/home/m3/work/cm3-ws/birch.elegosoft.com-2009-03-02-15-00-03/cm3/m3-sys/m3tests/src/Test.i3", line 8: unable to find interface (Usysdep) That's me. Sorry. I'll get to it tonight. In the meantime, feel free to roll it back. - Jay > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 3 Mar 2009 09:52:50 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 tinderbox status > > Hear hear. Things have been broken for days now... > > On 3 Mar 2009, at 09:13, Olaf Wagner wrote: > > > Being back in town, I find that over the weekend almost all of the > > m3 tests in tinderbox failed. What's going on there? > > > > I don't want to sound like Kassandra, especially since I'm not > > contributing actively myself currently, but I'd really like > > all committers to keep an eye on all the regression tests and > > fix things as soon as they fall off in quality. I've got the > > slight feeling that the overall quality of the M3 code base > > does not really increase currently. > > > > Please, let's all try to keep everything working as good as possible. > > If you check in something, monitor the effects in the various > > tinderbox regressions tests: > > > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > > http://www.opencm3.net/logs/package-status.html > > http://www.opencm3.net/m3tests/index.html > > > > Thanks in advance for your cooperation and help, > > > > Olaf > > > > PS: I also have the strong feeling that an official release is > > overdue. We should stop developing features and focus on building > > stable new distribution archives for a while. > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 3 01:02:05 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 3 Mar 2009 00:02:05 +0000 Subject: [M3devel] cm3 tinderbox status In-Reply-To: References: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> Message-ID: > In the meantime, feel free to roll it back. It being the test code that I added, changes only in m3-sys/m3tests. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] cm3 tinderbox status Date: Mon, 2 Mar 2009 23:56:46 +0000 I checked the status page, but there was no red. I see the large numbers now. Lots of +"/home/m3/work/cm3-ws/birch.elegosoft.com-2009-03-02-15-00-03/cm3/m3-sys/m3tests/src/Test.i3", line 8: unable to find interface (Usysdep) That's me. Sorry. I'll get to it tonight. In the meantime, feel free to roll it back. - Jay > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 3 Mar 2009 09:52:50 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 tinderbox status > > Hear hear. Things have been broken for days now... > > On 3 Mar 2009, at 09:13, Olaf Wagner wrote: > > > Being back in town, I find that over the weekend almost all of the > > m3 tests in tinderbox failed. What's going on there? > > > > I don't want to sound like Kassandra, especially since I'm not > > contributing actively myself currently, but I'd really like > > all committers to keep an eye on all the regression tests and > > fix things as soon as they fall off in quality. I've got the > > slight feeling that the overall quality of the M3 code base > > does not really increase currently. > > > > Please, let's all try to keep everything working as good as possible. > > If you check in something, monitor the effects in the various > > tinderbox regressions tests: > > > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > > http://www.opencm3.net/logs/package-status.html > > http://www.opencm3.net/m3tests/index.html > > > > Thanks in advance for your cooperation and help, > > > > Olaf > > > > PS: I also have the strong feeling that an official release is > > overdue. We should stop developing features and focus on building > > stable new distribution archives for a while. > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Mar 3 01:18:27 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Mar 2009 11:18:27 +1100 Subject: [M3devel] cm3 tinderbox status In-Reply-To: References: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> Message-ID: Looks like you introduced a dependence on Usysdep.i3 which is not present on all platforms. On 3 Mar 2009, at 10:56, Jay wrote: > I checked the status page, but there was no red. I see the large > numbers now. > > Lots of > +"/home/m3/work/cm3-ws/birch.elegosoft.com-2009-03-02-15-00-03/cm3/ > m3-sys/m3tests/src/Test.i3", line 8: unable to find interface > (Usysdep) > > That's me. Sorry. > I'll get to it tonight. > In the meantime, feel free to roll it back. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: wagner at elegosoft.com > > Date: Tue, 3 Mar 2009 09:52:50 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] cm3 tinderbox status > > > > Hear hear. Things have been broken for days now... > > > > On 3 Mar 2009, at 09:13, Olaf Wagner wrote: > > > > > Being back in town, I find that over the weekend almost all of the > > > m3 tests in tinderbox failed. What's going on there? > > > > > > I don't want to sound like Kassandra, especially since I'm not > > > contributing actively myself currently, but I'd really like > > > all committers to keep an eye on all the regression tests and > > > fix things as soon as they fall off in quality. I've got the > > > slight feeling that the overall quality of the M3 code base > > > does not really increase currently. > > > > > > Please, let's all try to keep everything working as good as > possible. > > > If you check in something, monitor the effects in the various > > > tinderbox regressions tests: > > > > > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > > > http://www.opencm3.net/logs/package-status.html > > > http://www.opencm3.net/m3tests/index.html > > > > > > Thanks in advance for your cooperation and help, > > > > > > Olaf > > > > > > PS: I also have the strong feeling that an official release is > > > overdue. We should stop developing features and focus on building > > > stable new distribution archives for a while. > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > > Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > > 45 86 95 > > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > > Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > > DE163214194 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 3 01:33:44 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 3 Mar 2009 00:33:44 +0000 Subject: [M3devel] cm3 tinderbox status In-Reply-To: References: <20090302231344.8wx207j0asgs0ggo@mail.elegosoft.com> Message-ID: Oops, right, I added it, oops, right it might not be on all platforms. I think we can trivially add it on all platforms with a small change in m3core/src/unix/common/m3makefile, even if it isn't otherwise used (yet), though it'll have to be present, and correct for the test to work, which it likely is. I realize it's not very valuable to use something /only/ in a test, but I hope to have it get more use, once user threading is implemented along with it. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 3 Mar 2009 11:18:27 +1100 CC: m3devel at elegosoft.com Subject: Re: [M3devel] cm3 tinderbox status Looks like you introduced a dependence on Usysdep.i3 which is not present on all platforms. On 3 Mar 2009, at 10:56, Jay wrote: I checked the status page, but there was no red. I see the large numbers now. Lots of +"/home/m3/work/cm3-ws/birch.elegosoft.com-2009-03-02-15-00-03/cm3/m3-sys/m3tests/src/Test.i3", line 8: unable to find interface (Usysdep) That's me. Sorry. I'll get to it tonight. In the meantime, feel free to roll it back. - Jay > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 3 Mar 2009 09:52:50 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 tinderbox status > > Hear hear. Things have been broken for days now... > > On 3 Mar 2009, at 09:13, Olaf Wagner wrote: > > > Being back in town, I find that over the weekend almost all of the > > m3 tests in tinderbox failed. What's going on there? > > > > I don't want to sound like Kassandra, especially since I'm not > > contributing actively myself currently, but I'd really like > > all committers to keep an eye on all the regression tests and > > fix things as soon as they fall off in quality. I've got the > > slight feeling that the overall quality of the M3 code base > > does not really increase currently. > > > > Please, let's all try to keep everything working as good as possible. > > If you check in something, monitor the effects in the various > > tinderbox regressions tests: > > > > http://tinderbox.elegosoft.com/tinderbox/cm3/status.html > > http://www.opencm3.net/logs/package-status.html > > http://www.opencm3.net/m3tests/index.html > > > > Thanks in advance for your cooperation and help, > > > > Olaf > > > > PS: I also have the strong feeling that an official release is > > overdue. We should stop developing features and focus on building > > stable new distribution archives for a while. > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rv82 at ya.ru Thu Mar 5 03:33:00 2009 From: rv82 at ya.ru (=?KOI8-R?B?98/Sz87P1yDyz83Bzg==?=) Date: Thu, 05 Mar 2009 05:33:00 +0300 Subject: [M3devel] Building DLLs for Win32 (NT386MINGNU) Message-ID: <291431236220380@webmail61.yandex.ru> Hello! Tell me please, how to build DLL in Win32 for using it with non Modula-3's programs? I use NT386MINGNU version of cm3. From jay.krell at cornell.edu Thu Mar 5 04:29:59 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 5 Mar 2009 03:29:59 +0000 Subject: [M3devel] Building DLLs for Win32 (NT386MINGNU) In-Reply-To: <291431236220380@webmail61.yandex.ru> References: <291431236220380@webmail61.yandex.ru> Message-ID: I think that is currently problematic. In particular, I don't think the Modula-3 runtime -- threading and garbage collection -- likes to be called on threads that were not created with it. I am also not sure that module initializers will get called if "main" is not written in Modula-3. Again, I'm not sure. I think I know how to mostly fix both of these problems, if they indeed both exist, though I think in general module initializers, like C++ static constructors, are problematic and cannot be implemented well. Modula-3 may be less problematic in a few ways -- in that the ordering is apparently guaranteed well defined or at least not circular, and, well, we may not have a legacy of calling them from DllMain, which is good and bad. DllMain is called with a lock held, giving you "free" serialization. However that also means you can't do much, without risk of deadlock, or of increasing contention (slowness) on that lock. A hybrid model might be viable, where if "main" is written in Modula-3, the initializers are all run early in main, outside the lock, but if "main" is not written in Modula-3, call the initializers from DllMain. In particular, one easy hack that comes to mind, is module initializers could see if the process's executable imports m3core.dll. If so, assume they will be called, else, not. Similar but less code is to export something from Modula-3 executables, a dummy marker, IAmWrittenWithModula3(), have the module initializers GetProcAddress and if it is not null.. (possibly something more general/extensible for the executable to "advertsize" arbitrary "properties" about itself). Initializers are also problematic because they often front load stuff unnecessarily -- do variables really all have to be initialized when the module loads, or only upon first use? Granted, doing it on first use implies an overhead for every use. But doing at load time implies a possibly unnecessary overhead for loading. But also, folks that do try on-demand initialization often get it wrong (i.e. not thread safe) -- I've fixed several examples around the Modula-3 tree, and I don't have a way to systematically find them, I just happen upon them. Cygwin has serious problems here too -- "main" not in something written using cygwin, leads to cygwin1.dll not being initialized easily/properly, and they seem to consider it not a problem. Some folks seem to have in mind relatively monolithic apps, all written using the same toolset and using the same runtime, while in reality many many apps are dynamically composed at load-time or run-time from separately authored pieces, "plugins" and such. The best example I have found here, of a simple application, that people might think is monolithic -- all dependencies known at build time or initial launch -- but is not actually monolithic -- is notepad. If you print from notepad, printer driver ui is dynamically loaded (indirectly) by it. Apart from Modula-3 and Cygwin1.dll, most .dlls handle their own initialization in their DllMain, and do not depend on their client to initialize them. The main counterexample is ole32.dll and its CoInitialize, which I think is kind of broken. Btw, this all meant to apply to NT386 and NT386MINGNU. They follow the same basic model. I'll look into this further, later. (see also: how do I catch a Modula-3 exception in C++, or a C++ exception in Modula-3? Answer: Don't/can't. Heck, there is no interop even from one C++ implementation to another..) - Jay > From: rv82 at ya.ru > To: m3devel at elegosoft.com > Date: Thu, 5 Mar 2009 05:33:00 +0300 > Subject: [M3devel] Building DLLs for Win32 (NT386MINGNU) > > Hello! > Tell me please, how to build DLL in Win32 for using it with non Modula-3's programs? I use NT386MINGNU version of cm3. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 5 16:52:46 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 5 Mar 2009 15:52:46 +0000 Subject: [M3devel] Building DLLs for Win32 (NT386MINGNU) In-Reply-To: <410661236228256@webmail2.yandex.ru> References: <291431236220380@webmail61.yandex.ru> <410661236228256@webmail2.yandex.ru> Message-ID: > From: rv82 at ya.ru > To: jay.krell at cornell.edu > Subject: Re: [M3devel] Building DLLs for Win32 (NT386MINGNU) > Date: Thu, 5 Mar 2009 07:44:16 +0300 > > And, Is it possible to use DLLs built with other languages? For example, > may I import DLL built by C in Modula-3 program? Definitely..just perhaps not stuff built with Cygwin (nothing to do with Modula-3, interop with Cygwin is slightly difficult even for C code built with another compiler/runtime). Basically, you have to rewrite your headers in Modula-3. Modula-3 "headers" are ".i3" files -- i for interface, 3 for Modula-3. And either LoadLibrary/GetProcAddress, or have an import .lib. In the Modula-3 you mark the functions with an "external" "pragma". Large example: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/win32/WinBase.i3?rev=1.7;content-type=text%2Fplain small example.. There were some nice small examples in the Critical Mass product. I can't find them online. Maybe... http://modula3.elegosoft.com/cm3/doc/index.html has a link "CM3 Examples" to http://modula3.elegosoft.com/cm3/doc/example/ but it doesn't work. I know this is kind of difficult to understand..but think about this..the Modula-3 compiler and runtime are written in Modula-3. They work. They read and write files, create threads, etc. -- they use the underlying system, which is composed of .dlls, which aren't written in Modula-3. Therefore, the answer to your question must be "yes". They call into the underlying system from Modula-3 using the same techniques as you would use. Of course, you also want to know how to do it, which this thought exercise does not immediately reveal -- you'd have to look at the compiler/runtime, find the calls to open files, etc., and trace them down. You would in fact eventually get to this WinBase.i3 file and its CreateFile declaration, but it takes searching through a few layers. Another thing you can do is run the compiler under a debugger and break on CreateFile (CreateFileA, CreateFileW) and look at the stack, and the file names on it. That can speed the search significantly. Oh, and WinBase.i3 wouldn't be on the stack, as the way it works, these declarations let other Modula-3 code call directly into the underlying system, without a "wrapper". (Well, lately I have been adding wrappers, for a good reason, but that is another matter.) Um, why do you favor NT386MINGNU/mingw over NT386/Visual C++? There is a free "beer" download, the "Express Edition", which should work. Have you tried that? I know there are reasons but I'm curious to know what yours are. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Mar 6 05:54:55 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 05 Mar 2009 23:54:55 -0500 Subject: [M3devel] Building DLLs for Win32 (NT386MINGNU) Message-ID: <49B0664F020000D7000537ED@scires.com> I'm reposting this because something went wrong when I tried sending earlier. This version has more complete info. --RCC >>> Jay 03/05/09 11:25 AM >>> .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:Verdana } ... There were some nice small examples in the Critical Mass product. I can't find them online. ... Jay, I checked in the examples folder back when I added the CM3IDE package. Indeed, if you use CM3IDE, it has a link directly to the examples index and it will let you build and run each example. You have to put the examples folder into your cm3 file tree as described in cm3/examples/README. This folder is in the repository! Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Mar 7 23:27:47 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 7 Mar 2009 22:27:47 +0000 Subject: [M3devel] PA32_HPUX available Message-ID: I have replaced these with: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-PA32_HPUX-d5.7.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-PA32_HPUX-d5.7.1.tar.lzma http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-PA32_HPUX-d5.7.1.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-PA32_HPUX-d5.7.1.tar.lzma These are "completely rebuilt", not just "repackaged". and also made sure that all the non-NT386 platforms have .tar.gz and .tar.lzma, and no .tar.bz2. Roughly/statistically speaking: .lzma is "always" much smaller than .gz, doesn't take too much longer to decompress, takes much longer to compress. .bz2 is "always" in between in size, and takes the longest to compress and decompress. lzma is the least widely deployed, gzip is the most widely deployed, bzip2 is somewhere in between. lzma is written in C++, which may negatively impact one's ability to build it. - Jay > From: jay.krell@ > To: m3devel@ > Subject: PA32_HPUX available > Date: Mon, 2 Mar 2009 15:48:44 +0000 > > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-PA32_HPUX-1.tar.gz > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-PA32_HPUX-1.tar.lzma > > > Here is a current build of PA32_HPUX, including all of "std". > > > The system builds itself and various gui apps startup. > Pthreads are used. User threads are not implemented. > The man page for get/set/make/swapcontext says they won't necessarily stay compatible. > > > Dynamic linking is supported and used. > > > This should match the current source tree, except my change to cm3cfg.common > isn't reflected here -- the backend is not itself optimized. > > > It requires the GNU C compiler and assembler -- gcc and gas. > > > It does not require, and probably won't work with, the GNU linker. > e.g. extract binutils and then rm -rf intl gold ld elfcpp binutils, > leaving just like libiberaty, bfd, opcodes, gas, > and then build it, or use -disable-x to not build those directories, > or build it all, but instead of install, just copy gas, it's just one file. > > > It might require getting up to date patches esp. for ld. > I was not able to build libstdc++ without patching ld, but > building libstdc++ is not necessary for Modula-3. It is a C++ thing. > > > I'm using HP-UX 11iv1 aka 11.11 (this is two versions out of date, > there is v2 and v3). > > > The cm3.cfg file in the archive delegates to > $CM3_ROOT/m3-sys/cminstall/src/config-no-install/PA32_HPUX. > and that file is somewhat specific to my configuration. > I can see about making it just use $PATH. > Problem is, on this sytem gcc doesn't support multilibs/-m32/-m64, > so you really need two separate "prefixes" and paths to work with > 32bit and 64bit targets, so I use /usr/local/32 and /usr/local/64. > > > It is possible to bootstrap to a good working system from > the bundled compiler, but you have to go through gcc 3.3.6 first. > > > There are my full paths in these binaries: > /cm3/lib/libm3core.sl.5 and such > > but you can set SHLIB_PATH to a colon delimited directory > that includes where you install to. > > > I haven't figured out yet how to omit the paths. > Perhaps we should use "$ORIGIN/../lib"? > > > Also, the stock HP-UX system does contain X or OpenGL headers/libs, > but they are a free download. Search the web. > At least the X headers/libs come with the unbundled compiler. > > mentor does not work. > It says: "*** Cannot create TCP port". > If $DISPLAY is not set correctly, the errors are not consistent. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 9 08:21:25 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 9 Mar 2009 07:21:25 +0000 Subject: [M3devel] subsecond resolution on file times? Message-ID: eh? We've got sub-second resolution, why not keep it? C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FSPosix.m3 PROCEDURE SetModificationTime(pn: Pathname.T; READONLY t: Time.T) RAISES {OSError.E}= CONST Accessed = 0; Updated = 1; VAR u: ARRAY [Accessed .. Updated] OF Utime.struct_timeval; fname := M3toC.SharedTtoS(pn); BEGIN u[Updated].tv_sec := ROUND(t); u[Updated].tv_usec := 0; u[Accessed].tv_sec := ROUND(Time.Now()); u[Accessed].tv_usec := 0; IF Unix.utimes(fname, ADR(u)) < 0 THEN Fail(pn, fname); END; M3toC.FreeSharedS(pn, fname); END SetModificationTime; http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html "The times in the timeval structure are measured in seconds and microseconds since the Epoch, although rounding toward the nearest second may occur." Rounding may occur, but won't necessarily. Are there systems that fail if tv_usec != 0? This is what TimePosix.ToUtime is for, eh? I was looking to see if I could remove Usysdep.struct_timeval, as part of reducing/eliminating Usysdep. The opengroup link says to use utime() instead of utimes() for portability? True? I'm skeptical. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Tue Mar 10 01:37:11 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Mon, 09 Mar 2009 19:37:11 -0500 Subject: [M3devel] Trestle question Message-ID: <49B5B637.3050702@bellsouth.net> Does CM3 support Trestle? I was trying some code from the Trestle Tutorial (DEC SRC Memo 69) but CM3 says it can't find TextVBT or Trestle. If it is still supported, is there a guide to how CM3 implements/uses it? From jay.krell at cornell.edu Tue Mar 10 01:51:58 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 10 Mar 2009 00:51:58 +0000 Subject: [M3devel] Trestle question In-Reply-To: <49B5B637.3050702@bellsouth.net> References: <49B5B637.3050702@bellsouth.net> Message-ID: It's definitely there and it should be about the same as it ever was. If you start with a "min" distribution, you need to built it yourself. If you start with "std", it should just be in there. - Jay > Date: Mon, 9 Mar 2009 19:37:11 -0500 > From: martinbishop at bellsouth.net > To: m3devel at elegosoft.com > Subject: [M3devel] Trestle question > > Does CM3 support Trestle? I was trying some code from the Trestle > Tutorial (DEC SRC Memo 69) but CM3 says it can't find TextVBT or Trestle. > > If it is still supported, is there a guide to how CM3 implements/uses it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 10 02:11:40 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 10 Mar 2009 01:11:40 +0000 Subject: [M3devel] Trestle question In-Reply-To: References: <49B5B637.3050702@bellsouth.net> Message-ID: Oh, maybe you need import() or something like that in your m3makefile? You probably do, but again, same as it mostly ever was. Poke around in the tree for gui apps like showthread, juno, etc., look at their m3makefiles. - Jay > From: martinbishop@ > To: m3devel@ > Subject: [M3devel] Trestle question > > Does CM3 support Trestle? -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Tue Mar 10 02:24:32 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Mon, 09 Mar 2009 20:24:32 -0500 Subject: [M3devel] Trestle question In-Reply-To: References: <49B5B637.3050702@bellsouth.net> Message-ID: <49B5C150.2000102@bellsouth.net> Jay wrote: > Oh, maybe you need import() or something like that in your m3makefile? > > You probably do, but again, same as it mostly ever was. > > Poke around in the tree for gui apps like showthread, juno, etc., > > look at their m3makefiles. > > > > - Jay > >> From: martinbishop@ >> To: m3devel@ >> Subject: [M3devel] Trestle question >> >> Does CM3 support Trestle? > Yeah, I wasn't used to using m3makefiles (just did 'cm3' in the directory). Anyway, I got it working, and am pleased with Trestle :) From wagner at elegosoft.com Wed Mar 11 11:39:43 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 11 Mar 2009 11:39:43 +0100 Subject: [M3devel] subsecond resolution on file times? In-Reply-To: References: Message-ID: <20090311113943.tyun2cpps0o8s4w0@mail.elegosoft.com> Quoting Jay : > > eh? We've got sub-second resolution, why not keep it? Offhand I don't see any reason to hide fine grained resolutions if the system supports them. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From martinbishop at bellsouth.net Fri Mar 13 18:55:42 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Fri, 13 Mar 2009 12:55:42 -0500 Subject: [M3devel] Classic Modula-3 Books Message-ID: <49BA9E1E.4090606@bellsouth.net> Is there any chance that "classic" books on Modula-3 like "Modula-3" by Harbison (I own a copy, it's a great book) or "Systems Programming With Modula-3" by Nelson might one day be released online? They aren't in print anymore, and I can't imagine there is much demand for them...I found "Modula-3" used for $1 on Amazon, but "Systems Programming With Modula-3" is $40 at it's cheapest, used :( From martinbishop at bellsouth.net Sat Mar 14 08:22:31 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Sat, 14 Mar 2009 02:22:31 -0500 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <200903140704.n2E74S3i079116@camembert.async.caltech.edu> References: <200903140704.n2E74S3i079116@camembert.async.caltech.edu> Message-ID: <49BB5B37.5000907@bellsouth.net> Where is Nelson's book available? I don't think I ever saw it? Unless you mean in DEC memos or something? Mika Nystrom wrote: > Hi Martin, > > I once emailed the publisher about permission to reproduce parts of > these books for a class I was teaching, and all I got was silence. > > Harbison's book was listed as a "print on demand" book for a while, > if I remember right. Most of Nelson's book is already available > online (which chapters are not?), albeit in a less organized way. > > Last time I bought Nelson, I found it cheaper at amazon.co.uk, > and they had several copies for < $10. Try www.addall.com or a > similar search engine... > > Mika > > Martin Bishop writes: >> Is there any chance that "classic" books on Modula-3 like "Modula-3" by >> Harbison (I own a copy, it's a great book) or "Systems Programming With >> Modula-3" by Nelson might one day be released online? >> >> They aren't in print anymore, and I can't imagine there is much demand >> for them...I found "Modula-3" used for $1 on Amazon, but "Systems >> Programming With Modula-3" is $40 at it's cheapest, used :( > From mika at async.caltech.edu Sat Mar 14 11:55:02 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 14 Mar 2009 03:55:02 -0700 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: Your message of "Sat, 14 Mar 2009 02:22:31 CDT." <49BB5B37.5000907@bellsouth.net> Message-ID: <200903141055.n2EAt2IS087290@camembert.async.caltech.edu> Right, most (if not all) of the chapters are available as SRC research reports. I find the book very convenient so I have three or four copies of it, but if you don't want to spend the money I think you can assemble it yourself. Mika Martin Bishop writes: >Where is Nelson's book available? I don't think I ever saw it? Unless >you mean in DEC memos or something? > >Mika Nystrom wrote: >> Hi Martin, >> >> I once emailed the publisher about permission to reproduce parts of >> these books for a class I was teaching, and all I got was silence. >> >> Harbison's book was listed as a "print on demand" book for a while, >> if I remember right. Most of Nelson's book is already available >> online (which chapters are not?), albeit in a less organized way. >> >> Last time I bought Nelson, I found it cheaper at amazon.co.uk, >> and they had several copies for < $10. Try www.addall.com or a >> similar search engine... >> >> Mika >> >> Martin Bishop writes: >>> Is there any chance that "classic" books on Modula-3 like "Modula-3" by >>> Harbison (I own a copy, it's a great book) or "Systems Programming With >>> Modula-3" by Nelson might one day be released online? >>> >>> They aren't in print anymore, and I can't imagine there is much demand >>> for them...I found "Modula-3" used for $1 on Amazon, but "Systems >>> Programming With Modula-3" is $40 at it's cheapest, used :( >> From hendrik at topoi.pooq.com Fri Mar 13 21:23:59 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 13 Mar 2009 16:23:59 -0400 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <49BA9E1E.4090606@bellsouth.net> References: <49BA9E1E.4090606@bellsouth.net> Message-ID: <20090313202359.GB17743@topoi.pooq.com> On Fri, Mar 13, 2009 at 12:55:42PM -0500, Martin Bishop wrote: > Is there any chance that "classic" books on Modula-3 like "Modula-3" by > Harbison (I own a copy, it's a great book) or "Systems Programming With > Modula-3" by Nelson might one day be released online? > > They aren't in print anymore, and I can't imagine there is much demand > for them...I found "Modula-3" used for $1 on Amazon, but "Systems > Programming With Modula-3" is $40 at it's cheapest, used :( Is there any chance of contacting the author(s)? -- hendrik From rodney.bates at wichita.edu Fri Mar 13 22:31:24 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 13 Mar 2009 16:31:24 -0500 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <49BA9E1E.4090606@bellsouth.net> References: <49BA9E1E.4090606@bellsouth.net> Message-ID: <49BAD0AC.6050806@wichita.edu> I have maybe 2 or 3 copies of SPwM3. I have occasionally thought about trying to acquire the copyright from Prentice-Hall, but never got around to investigating. There are others: Harbison: "Modula-3", also Prentice-Hall Boszormenyi & Weich "Programming in Modula-3", Springer-Verlag Sedgewick: Algorithms in Modula-3", Addison-Wesley I am especially interested in the last one. The second and third are language tutorials. Does anyone have any idea whether it is better to first contact the author or the publisher? Presumably, the publisher owns all rights, but there is a royalty contract with the author. Perhaps we could create a nonprofit foundation or something, to receive copyrights by whatever means and hold them to keep things like this available. Martin Bishop wrote: > Is there any chance that "classic" books on Modula-3 like "Modula-3" by > Harbison (I own a copy, it's a great book) or "Systems Programming With > Modula-3" by Nelson might one day be released online? > > They aren't in print anymore, and I can't imagine there is much demand > for them...I found "Modula-3" used for $1 on Amazon, but "Systems > Programming With Modula-3" is $40 at it's cheapest, used :( From mika at async.caltech.edu Sat Mar 14 08:04:28 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 14 Mar 2009 00:04:28 -0700 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: Your message of "Fri, 13 Mar 2009 12:55:42 CDT." <49BA9E1E.4090606@bellsouth.net> Message-ID: <200903140704.n2E74S3i079116@camembert.async.caltech.edu> Hi Martin, I once emailed the publisher about permission to reproduce parts of these books for a class I was teaching, and all I got was silence. Harbison's book was listed as a "print on demand" book for a while, if I remember right. Most of Nelson's book is already available online (which chapters are not?), albeit in a less organized way. Last time I bought Nelson, I found it cheaper at amazon.co.uk, and they had several copies for < $10. Try www.addall.com or a similar search engine... Mika Martin Bishop writes: >Is there any chance that "classic" books on Modula-3 like "Modula-3" by >Harbison (I own a copy, it's a great book) or "Systems Programming With >Modula-3" by Nelson might one day be released online? > >They aren't in print anymore, and I can't imagine there is much demand >for them...I found "Modula-3" used for $1 on Amazon, but "Systems >Programming With Modula-3" is $40 at it's cheapest, used :( From martinbishop at bellsouth.net Sat Mar 14 19:52:02 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Sat, 14 Mar 2009 13:52:02 -0500 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <20090313202359.GB17743@topoi.pooq.com> References: <49BA9E1E.4090606@bellsouth.net> <20090313202359.GB17743@topoi.pooq.com> Message-ID: <49BBFCD2.5000505@bellsouth.net> Well, I looked around, but it's surprisingly hard to find Greg Nelson... I believe his full name is actually Charles Greg Nelson, but it's still difficult...I think he was last at HP in 2007? No idea where he works now, nor where he could be contacted. hendrik at topoi.pooq.com wrote: > On Fri, Mar 13, 2009 at 12:55:42PM -0500, Martin Bishop wrote: >> Is there any chance that "classic" books on Modula-3 like "Modula-3" by >> Harbison (I own a copy, it's a great book) or "Systems Programming With >> Modula-3" by Nelson might one day be released online? >> >> They aren't in print anymore, and I can't imagine there is much demand >> for them...I found "Modula-3" used for $1 on Amazon, but "Systems >> Programming With Modula-3" is $40 at it's cheapest, used :( > > Is there any chance of contacting the author(s)? > > -- hendrik > > From martinbishop at bellsouth.net Sat Mar 14 19:50:39 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Sat, 14 Mar 2009 13:50:39 -0500 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <49BAD0AC.6050806@wichita.edu> References: <49BA9E1E.4090606@bellsouth.net> <49BAD0AC.6050806@wichita.edu> Message-ID: <49BBFC7F.4070704@bellsouth.net> I too am interested in the Sedgewick book, which seems very rare. Let me know if you ever find it somewhere for a good price. Rodney M. Bates wrote: > I have maybe 2 or 3 copies of SPwM3. I have occasionally thought about > trying to acquire the copyright from Prentice-Hall, but never got around > to investigating. > > There are others: > > Harbison: "Modula-3", also Prentice-Hall > Boszormenyi & Weich "Programming in Modula-3", Springer-Verlag > Sedgewick: Algorithms in Modula-3", Addison-Wesley > > I am especially interested in the last one. The second and third > are language tutorials. > > Does anyone have any idea whether it is better to first contact the author > or the publisher? Presumably, the publisher owns all rights, but there > is a royalty contract with the author. > > Perhaps we could create a nonprofit foundation or something, to receive > copyrights by whatever means and hold them to keep things like this > available. > > > Martin Bishop wrote: >> Is there any chance that "classic" books on Modula-3 like "Modula-3" by >> Harbison (I own a copy, it's a great book) or "Systems Programming With >> Modula-3" by Nelson might one day be released online? >> >> They aren't in print anymore, and I can't imagine there is much demand >> for them...I found "Modula-3" used for $1 on Amazon, but "Systems >> Programming With Modula-3" is $40 at it's cheapest, used :( > > From martinbishop at bellsouth.net Sat Mar 14 20:20:05 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Sat, 14 Mar 2009 14:20:05 -0500 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <94E563AF-610A-4417-9A4D-05D2F253E0AC@cs.purdue.edu> References: <49BA9E1E.4090606@bellsouth.net> <20090313202359.GB17743@topoi.pooq.com> <49BBFCD2.5000505@bellsouth.net> <94E563AF-610A-4417-9A4D-05D2F253E0AC@cs.purdue.edu> Message-ID: <49BC0365.1070101@bellsouth.net> Ah, and from the email I found http://www.perlnelson.org/ which seems to be a website for the Nelson family. I suppose that would be a good place to contact him. Tony Hosking wrote: > Last contact I had with Greg Nelson was this e-mail... > > Begin forwarded message: >> From: "Greg Nelson" >> Date: 25 March 2006 10:43:52 GMT+11:00 >> To: hosking at cs.purdue.edu >> Subject: Some progress >> Reply-To: greg at perlnelson.org >> >> Antony, >> >> Thank you for your help. By following your advice I have successfully >> downloaded CM3 to my Linux machine, and used it to compile and execute >> the program that prints "Hello world". But when I try to apply it to >> an m3makefile that imports "ui" and compiles a program that >> Trestle.Installs a TextVBT that displays the text "Hello Trestle", I >> get an error message that I interpret to mean "ui package not found". >> And I am concerned that I cannot find any evidence of the ui package >> or of the Juno-2 packages that are my goal. (I hope to use Juno-2 to >> produce an educational video.) >> >> Is there still hope? Would you like to suggest a next step for me? >> >> >> Greg Nelson >> greg at perlnelson.org >> 839 Richardson Ct Palo Alto, CA USA 94303 >> (650) 856 8103 (home) (650) 856 8103 (office) (650) 954 5338 (mobile) > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 15 Mar 2009, at 05:52, Martin Bishop wrote: > >> Well, I looked around, but it's surprisingly hard to find Greg Nelson... >> I believe his full name is actually Charles Greg Nelson, but it's still >> difficult...I think he was last at HP in 2007? No idea where he works >> now, nor where he could be contacted. >> >> hendrik at topoi.pooq.com wrote: >>> On Fri, Mar 13, 2009 at 12:55:42PM -0500, Martin Bishop wrote: >>>> Is there any chance that "classic" books on Modula-3 like "Modula-3" by >>>> Harbison (I own a copy, it's a great book) or "Systems Programming With >>>> Modula-3" by Nelson might one day be released online? >>>> >>>> They aren't in print anymore, and I can't imagine there is much demand >>>> for them...I found "Modula-3" used for $1 on Amazon, but "Systems >>>> Programming With Modula-3" is $40 at it's cheapest, used :( >>> >>> Is there any chance of contacting the author(s)? >>> >>> -- hendrik >>> >>> > > From hosking at cs.purdue.edu Sat Mar 14 20:16:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 15 Mar 2009 06:16:26 +1100 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <49BBFCD2.5000505@bellsouth.net> References: <49BA9E1E.4090606@bellsouth.net> <20090313202359.GB17743@topoi.pooq.com> <49BBFCD2.5000505@bellsouth.net> Message-ID: <94E563AF-610A-4417-9A4D-05D2F253E0AC@cs.purdue.edu> Last contact I had with Greg Nelson was this e-mail... Begin forwarded message: > From: "Greg Nelson" > Date: 25 March 2006 10:43:52 GMT+11:00 > To: hosking at cs.purdue.edu > Subject: Some progress > Reply-To: greg at perlnelson.org > > Antony, > > Thank you for your help. By following your advice I have > successfully downloaded CM3 to my Linux machine, and used it to > compile and execute the program that prints "Hello world". But when > I try to apply it to an m3makefile that imports "ui" and compiles a > program that Trestle.Installs a TextVBT that displays the text > "Hello Trestle", I get an error message that I interpret to mean "ui > package not found". And I am concerned that I cannot find any > evidence of the ui package or of the Juno-2 packages that are my > goal. (I hope to use Juno-2 to produce an educational video.) > > Is there still hope? Would you like to suggest a next step for me? > > > Greg Nelson > greg at perlnelson.org > 839 Richardson Ct Palo Alto, CA USA 94303 > (650) 856 8103 (home) (650) 856 8103 (office) (650) 954 5338 (mobile) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Mar 2009, at 05:52, Martin Bishop wrote: > Well, I looked around, but it's surprisingly hard to find Greg > Nelson... > I believe his full name is actually Charles Greg Nelson, but it's > still > difficult...I think he was last at HP in 2007? No idea where he works > now, nor where he could be contacted. > > hendrik at topoi.pooq.com wrote: >> On Fri, Mar 13, 2009 at 12:55:42PM -0500, Martin Bishop wrote: >>> Is there any chance that "classic" books on Modula-3 like >>> "Modula-3" by >>> Harbison (I own a copy, it's a great book) or "Systems Programming >>> With >>> Modula-3" by Nelson might one day be released online? >>> >>> They aren't in print anymore, and I can't imagine there is much >>> demand >>> for them...I found "Modula-3" used for $1 on Amazon, but "Systems >>> Programming With Modula-3" is $40 at it's cheapest, used :( >> >> Is there any chance of contacting the author(s)? >> >> -- hendrik >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Mar 15 00:00:59 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 15 Mar 2009 00:00:59 +0100 (CET) Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <49BAD0AC.6050806@wichita.edu> References: <49BA9E1E.4090606@bellsouth.net> <49BAD0AC.6050806@wichita.edu> Message-ID: On Fri, 13 Mar 2009, Rodney M. Bates wrote: > I have maybe 2 or 3 copies of SPwM3. I have occasionally thought about > trying to acquire the copyright from Prentice-Hall, but never got around > to investigating. > > There are others: > > Harbison: "Modula-3", also Prentice-Hall > Boszormenyi & Weich "Programming in Modula-3", Springer-Verlag > Sedgewick: Algorithms in Modula-3", Addison-Wesley > > I am especially interested in the last one. The second and third > are language tutorials. I was very disappointed when I got the Sedgewick book. They explicitly try to not use nice language features in their variants for several languages, so this is C translated to Modula-3. They don't use enumeration types although this is often most appropriate, they use global variables without need, I remember they don't use NEW, etc. I think it's better to have the C variant of the book and enjoy porting and thus simplifying the programs to good style Modula-3. From jay.krell at cornell.edu Sun Mar 15 00:20:06 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 14 Mar 2009 23:20:06 +0000 Subject: [M3devel] Classic Modula-3 Books In-Reply-To: <49BBFC7F.4070704@bellsouth.net> References: <49BA9E1E.4090606@bellsouth.net> <49BAD0AC.6050806@wichita.edu> <49BBFC7F.4070704@bellsouth.net> Message-ID: Amazon has a few copies of the Sedgewick book used for under $50. Just search, on the Amazon site, for "robert sedgewick modula-3". Indeed they only show one new copy, for $200. - Jay > Date: Sat, 14 Mar 2009 13:50:39 -0500 > From: martinbishop@ > > I too am interested in the Sedgewick book, which seems very rare. Let > me know if you ever find it somewhere for a good price. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Mar 15 11:24:09 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 15 Mar 2009 10:24:09 +0000 Subject: [M3devel] linuxlibc6 jmpbuf size? Message-ID: The Linuxlibc6 jmpbuf size looks clearly wrong, just slightly inflated. It should be 39 * address, not 40. Any objections to fixing it? This is the one that fits the signal mask. Only 6 addresses are needed if signal mask isn't saved. Plus 1 to record if it is saved. Plus 1024 bits for a glibc signal mask, even though the kernel only supports 128 signals on mips and 64 on all others..big waste imho.. 6 + 1 + 1024/32 = 39. Hm. I rather think we should shorten it to 6, 7, or 11 really, after confirming we can. (11: 6 for registers, 1 to indicate if signal mask saved, 4 for signal mask; or 7: 6 for registers and 1 to hold zero to indicate signal mask not saved; or 6: registers and implied/known no signal mask saved, if that is the case, I have to check). See http://lists.uclibc.org/pipermail/uclibc/2008-December/041674.html for details on the signal mask size.. - Jay From hosking at cs.purdue.edu Sun Mar 15 17:05:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Mar 2009 03:05:58 +1100 Subject: [M3devel] linuxlibc6 jmpbuf size? In-Reply-To: References: Message-ID: Have you checked all the alignments? On 15 Mar 2009, at 21:24, Jay wrote: > > The Linuxlibc6 jmpbuf size looks clearly wrong, just slightly > inflated. > It should be 39 * address, not 40. > Any objections to fixing it? > > > This is the one that fits the signal mask. > Only 6 addresses are needed if signal mask isn't saved. > Plus 1 to record if it is saved. > Plus 1024 bits for a glibc signal mask, even though the kernel only > supports 128 signals on mips and 64 on all others..big waste imho.. > > > 6 + 1 + 1024/32 = 39. > > Hm. I rather think we should shorten it to 6, 7, or 11 really, after > confirming we can. > (11: 6 for registers, 1 to indicate if signal mask saved, 4 for > signal mask; or 7: 6 for registers and 1 to hold zero to indicate > signal mask not saved; or 6: registers and implied/known no signal > mask saved, if that is the case, I have to check). > > See > http://lists.uclibc.org/pipermail/uclibc/2008-December/041674.html > > for details on the signal mask size.. > > - Jay From jay.krell at cornell.edu Sun Mar 15 19:13:32 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 15 Mar 2009 18:13:32 +0000 Subject: [M3devel] linuxlibc6 jmpbuf size? In-Reply-To: References: Message-ID: I hadn't, but it is 4, and that is factored into printing the size in C, though not factored into adding up the size by hand. I did both. I first noticed the disprepancy when a change I had locally made Csetjmp.i3 not compile, (missing Usignal.sigset_t) so I ran config.c. Though since config.c is kind of complicated, also ran: jay at localhost ~ $ uname -a Linux localhost 2.6.25-gentoo-r7 #5 Sun Oct 5 18:59:56 Local time zone must be set--see zic manua i5 86 Geode(TM) Integrated Processor by AMD PCS AuthenticAMD GNU/Linux jay at localhost ~ $ cat 1.c #include #include typedef unsigned U; int main() { jmp_buf jb[2]; printf("%u\n", (U)sizeof(jb)); printf("%u\n", (U)sizeof(jmp_buf)); printf("%u\n", (U)__alignof(jmp_buf)); return 0; } jay at localhost ~ $ cc 1.c .jay at localhost ~ $ ./a.out 312 156 4 (eek, hadn't noticed the clock being wrong before, though I had noticed the timezone) - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] linuxlibc6 jmpbuf size? > Date: Mon, 16 Mar 2009 03:05:58 +1100 > > Have you checked all the alignments? > > On 15 Mar 2009, at 21:24, Jay wrote: > >> >> The Linuxlibc6 jmpbuf size looks clearly wrong, just slightly >> inflated. >> It should be 39 * address, not 40. >> Any objections to fixing it? >> >> >> This is the one that fits the signal mask. >> Only 6 addresses are needed if signal mask isn't saved. >> Plus 1 to record if it is saved. >> Plus 1024 bits for a glibc signal mask, even though the kernel only >> supports 128 signals on mips and 64 on all others..big waste imho.. >> >> >> 6 + 1 + 1024/32 = 39. >> >> Hm. I rather think we should shorten it to 6, 7, or 11 really, after >> confirming we can. >> (11: 6 for registers, 1 to indicate if signal mask saved, 4 for >> signal mask; or 7: 6 for registers and 1 to hold zero to indicate >> signal mask not saved; or 6: registers and implied/known no signal >> mask saved, if that is the case, I have to check). >> >> See >> http://lists.uclibc.org/pipermail/uclibc/2008-December/041674.html >> >> for details on the signal mask size.. >> >> - Jay > From jay.krell at cornell.edu Sun Mar 15 20:15:56 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 15 Mar 2009 19:15:56 +0000 Subject: [M3devel] recent problems? Message-ID: I'm seeing some problems lately. Maybe it is just me. Some of them I've had over a week (ie: before my (most) recent changes), some of them even if recently appeared I verified without my (most) recent changes. On Cygwin 1.5, mklib always crashes. I haven't been able to debug it. This has been over a week. I've had to stop using Cygwin for Modula-3 development on this machine. I have a good repro but hadn't had luck yet debugging it. Basically if I shorten the mklib command line (in the response file) substantially, no crash. There is a cut off somewhere. On Cygwin 1.7 machine, stubgen in obliqparse usually but not always hangs. It hangs nowhere else. This I verified occured without my recent changes. I only just in the past few days tried Cygwin 1.7. mklib works fine here. Of course since this is somewhat intermittent, maybe it isn't a new problem. I've only tried Cygwin 1.5 and 1.7 on one machine each, separate machines, though they do coexist ok on one machine. 1.7 seemed much faster (on an unimpressive machine), though 1.7 binares apparently don't run on 1.5 -- at least not if they use assert(). 1.7 is a recent past or future release, a long time in the works, drops Win9x support, lots of good sounding changes. I should run m3tests more, maybe they will reveal the crash or the hang as well. On LINUXLIBC6 on one machine stubgen was crashing at least in one directory. But I think this stopped happening. Cygwin being broken pushes me to other platforms more, probably a good thing. I'm loathe to debug the hang. When it occurs I can't see any stacks in gdb. I can see in strace.. I think we are waiting for all the threads to suspend themselves. I'll probably try moving back to Win32 threads and see if it clears up. I know that's not great. There isn't a clear implied question and I know I should/need to look into these, but I also thought I shouldn't keep this to myself. I also understand the philosophy of stopping changes when there are problems, to stop further damage, but, of course, I'm very confident in my changes (always..), have been testing them on other platforms, and looking them over extra extra since I know of these other problems. I'm not sure any problem on Cygwin is worrisome really. I think the underlying code is kind of gnarly and I don't think anyone uses this platform, though people asked for it. But I did have a crash on LINUXLIBC6. - Jay From hosking at cs.purdue.edu Sun Mar 15 22:10:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Mar 2009 08:10:05 +1100 Subject: [M3devel] recent problems? In-Reply-To: References: Message-ID: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> You might have structure sizes wrong and your stack will get shifted around as the command line changes length. You get some data in a structure wrong and then hit the wrong stack org and you might see problems like this. I am not running things totally off of the head, so if the problem was introduced recently it might only now be seen. On 16 Mar 2009, at 06:15, Jay wrote: > > I'm seeing some problems lately. Maybe it is just me. > Some of them I've had over a week (ie: before my (most) recent > changes), > some of them even if recently appeared I verified without my (most) > recent changes. > > On Cygwin 1.5, mklib always crashes. I haven't been able to debug it. > This has been over a week. > I've had to stop using Cygwin for Modula-3 development on this > machine. > I have a good repro but hadn't had luck yet debugging it. > Basically if I shorten the mklib command line (in the response > file) substantially, no crash. > There is a cut off somewhere. > > On Cygwin 1.7 machine, stubgen in obliqparse usually but not always > hangs. > It hangs nowhere else. > This I verified occured without my recent changes. > I only just in the past few days tried Cygwin 1.7. > mklib works fine here. > Of course since this is somewhat intermittent, maybe it isn't a new > problem. > > I've only tried Cygwin 1.5 and 1.7 on one machine each, separate > machines, > though they do coexist ok on one machine. > 1.7 seemed much faster (on an unimpressive machine), though 1.7 > binares > apparently don't run on 1.5 -- at least not if they use assert(). > 1.7 is a recent past or future release, a long time in the works, > drops Win9x support, lots of good sounding changes. > > I should run m3tests more, maybe they will reveal the crash or the > hang as well. > > On LINUXLIBC6 on one machine stubgen was crashing at least in one > directory. > But I think this stopped happening. > > Cygwin being broken pushes me to other platforms more, probably a > good thing. > I'm loathe to debug the hang. When it occurs I can't see any stacks > in gdb. I can see in strace.. > I think we are waiting for all the threads to suspend themselves. > I'll probably try moving back to Win32 threads and see if it clears > up. > I know that's not great. > There isn't a clear implied question and I know I should/need to > look into these, > but I also thought I shouldn't keep this to myself. I also > understand the philosophy > of stopping changes when there are problems, to stop further > damage, but, of course, > I'm very confident in my changes (always..), have been testing them > on other platforms, > and looking them over extra extra since I know of these other > problems. > > I'm not sure any problem on Cygwin is worrisome really. > I think the underlying code is kind of gnarly and I don't think > anyone uses this platform, though people asked for it. > But I did have a crash on LINUXLIBC6. > > - Jay From martinbishop at bellsouth.net Mon Mar 16 01:22:59 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Sun, 15 Mar 2009 19:22:59 -0500 Subject: [M3devel] [Fwd: Re: "Systems Programming With Modula-3" available?] Message-ID: <49BD9BE3.6050900@bellsouth.net> This is the email (and response) I got from Greg Nelson. -------------- next part -------------- An embedded message was scrubbed... From: Greg Nelson Subject: Re: "Systems Programming With Modula-3" available? Date: Sun, 15 Mar 2009 14:49:03 -0700 Size: 3045 URL: From jay.krell at cornell.edu Mon Mar 16 02:09:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 01:09:52 +0000 Subject: [M3devel] FW: trimmed down more portable Unix *.i3 files In-Reply-To: <20090316003949.40CB110D60EA@birch.elegosoft.com> References: <20090316003949.40CB110D60EA@birch.elegosoft.com> Message-ID: This is a significant change. I have used these files (older versions often) on a number of platforms already: AMD64_{LINUX,FREEBSD}, I386_OPENBSD, PA32_HPUX, incomplete PA64_HPUX, Cygwin, PPC_LINUX, SPARC64_SOLARIS, MIP64_OPENBSD (I don't think I finished that), others maybe. - Jay ---------------------------------------- > Date: Mon, 16 Mar 2009 01:39:49 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/03/16 01:39:49 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: m3makefile > cm3/m3-libs/m3core/src/unix/linux-libc6/: m3makefile > > Log message: > switch LINUXLIBC6 to the trimmed down more portable Unix *.i3 files, > except for Usignal.i3 and Uucontext.i3. Usignal.i3 and Uucontext.i3 > are left alone in order to keep the user thread code compilable, > though it is not expected to work for other long standing reasons. > From jay.krell at cornell.edu Mon Mar 16 02:39:51 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 01:39:51 +0000 Subject: [M3devel] eliminating platform-specifity of pthread_t? Message-ID: pthread_t 1) do nothing; leave it as platform-dependent 2) Widen it to INTEGER or ADDRESS and declare that is portable and correct. Put in an assert that pthread_t fits in size_t/void*. This is often correct, and where it isn't, it is probably ok. correct: OpenBSD, FreeBSD, NetBSD, all or probably all 32bit platforms, Cygwin, Darwin, Linux wasteful: 64bit HP-UX, 64bit Solaris; which apparently both always use a 32bit integer for pthread_t not yet determined: Tru64, AIX, Irix (including 32bit AIX, Irix; I have these systems.) Given that its neighbors on both sides are pointers, this isn't likely to consume any extra space on most platforms (but maybe on AMD64_SOLARIS?) Odds are high that passing a pointer instead of 32bit integer is ok on all platforms, but wrappers can be introduced to make that safer, like how I did for mode_t. 3) Some sort of C wrapping, that I haven't thought of yet. Well, there are some candidates, more and less satisfactory. 3a) heap allocate it; not satisfactory 3b) Put it at the end of Activation and use it with C wrappers fairly satisfactory, just that the system-dependent FloatMode.ThreadState and RTHeapRep.ThreadState have to be accounted for, somehow. Either by having the C know their definition on all platforms, ok. Or by having the Modula-3 code pass that data to the C code. These are both signficantly less satisfactory imho than any other C wrapping I have put in. I think #2 with wrappers is my favorite. - Jay From carson at taltos.org Mon Mar 16 04:38:27 2009 From: carson at taltos.org (Carson Gaspar) Date: Sun, 15 Mar 2009 20:38:27 -0700 Subject: [M3devel] cvsup and cm3 - drama galore! Any help for Uexec_WNOHANG? Message-ID: <49BDC9B3.3020808@taltos.org> I want to end up with a working cvsup for our RHEL5 U4 x86_64 servers (a working 32-bit binary is fine...). So I tried building cm3 and ran into problems trying to bootstrap. The list archives said "use newer source". So I tried. And the latest snapshots failed to build. I saw a message complaining about the regression (sadly sans solution), so I grabbed source from CVS as of Jan 31, 2009. That built! So now I try building cvsup. Then I apply the cm3 patch and try again. Then I manually hack "SchedulerPOSIX" to "Scheduler" and try again (thank my lucky stars for Google!). So now I _almost_ have it building, but it fails on FSServerU.m3, complaining about an undefined reference to Uexec_WNOHANG. And here I sit, stumped. I see a C sourse file Uconstants.c in the cm3 distribution that looks like it _ought_ to define it, but obviously something is unhappy... When was the last time somebody successfully built cvsup with cm3 on Linux? I'll gladly bootstrap from some known good point, but I'd rather avoid doing a binary search to find a working compiler... -- Carson From hendrik at topoi.pooq.com Mon Mar 16 03:07:02 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 15 Mar 2009 22:07:02 -0400 Subject: [M3devel] [Fwd: Re: "Systems Programming With Modula-3" available?] In-Reply-To: <49BD9BE3.6050900@bellsouth.net> References: <49BD9BE3.6050900@bellsouth.net> Message-ID: <20090316020702.GC24734@topoi.pooq.com> On Sun, Mar 15, 2009 at 07:22:59PM -0500, Martin Bishop wrote: > This is the email (and response) I got from Greg Nelson. > X-Account-Key: account2 > X-Mozilla-Keys: > Authentication-Results: isp.att.net; > domainkey=pass (no signature error) header.From=gnelson at gmail.com > Authentication-Results: isp.att.net; > dkim=pass (no signature error) header.i=@gmail.com > X-Originating-IP: [209.85.198.246] > Reply-To: greg at perlnelson.org > Subject: Re: "Systems Programming With Modula-3" available? > From: Greg Nelson > To: Martin Bishop > > I haven't studied the contract with Prentice-Hall, but I'm afraid it > is bound to give them the copyright. I have asked them before to > please print a second edition. I will try again. If they refuse, I'm > not sure there is anything I can do to help. But in case it is of any > help to you, I will remark that II think that the TeX sources for the > book are stored among the publicly released Modula-3 packages. Which puts the whole thing in a difficult legal position. If the rights were given away under the original Modula-3 license, just what did Prentice-Hall buy, what did they think they bought, and what legal position will that put Greg? And if they were sold to Prentice-Hall before they were given away, just what was given away? And if Prentice-Hall refuses even to reprint and the book has been years out of pront, what rights revert to Greg? There are standard contract terms here (which Prentice hall may not have used) and there is applicable law, which varies from country to country. For example, Canadian law permits some copying of entire books under some circumstance if they are permanently out of print.... Even if Prentice-Hall refuses, they may be willing to return the rights to a book they have no intention of ever reprinting. -- hendrik From wagner at elegosoft.com Mon Mar 16 07:47:09 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 16 Mar 2009 07:47:09 +0100 Subject: [M3devel] cvsup and cm3 - drama galore! Any help for Uexec_WNOHANG? In-Reply-To: <49BDC9B3.3020808@taltos.org> References: <49BDC9B3.3020808@taltos.org> Message-ID: <20090316074709.xoymn3nx0gk8ggc4@mail.elegosoft.com> Quoting Carson Gaspar : > I want to end up with a working cvsup for our RHEL5 U4 x86_64 servers (a > working 32-bit binary is fine...). > > So I tried building cm3 and ran into problems trying to bootstrap. The > list archives said "use newer source". So I tried. And the latest > snapshots failed to build. I saw a message complaining about the > regression (sadly sans solution), so I grabbed source from CVS as of Jan > 31, 2009. That built! > > So now I try building cvsup. Then I apply the cm3 patch and try again. > Then I manually hack "SchedulerPOSIX" to "Scheduler" and try again > (thank my lucky stars for Google!). So now I _almost_ have it building, > but it fails on FSServerU.m3, complaining about an undefined reference > to Uexec_WNOHANG. And here I sit, stumped. I see a C sourse file > Uconstants.c in the cm3 distribution that looks like it _ought_ to > define it, but obviously something is unhappy... > > When was the last time somebody successfully built cvsup with cm3 on > Linux? I'll gladly bootstrap from some known good point, but I'd rather > avoid doing a binary search to find a working compiler... It's not Linux, it's the 64 bit targets on Intel processors which are rather new and unpolished. I don't think the WNOHANG problem is due to that, though; I rather think it may have been `optimized away' during a perhaps too rigorous code clean-up recently. Jay, could it be that this constant is acceidently missing in newer sources? This reminds me that we should add cvsup as a cm3 project and include it in our regression tests. I'll try to do that some time soon. Don't panic; we'll be able to get cvsup to compile ;-) Regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Mar 16 08:54:53 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 07:54:53 +0000 Subject: [M3devel] cvsup and cm3 - minor problems Any help for Uexec_WNOHANG? In-Reply-To: <20090316074709.xoymn3nx0gk8ggc4@mail.elegosoft.com> References: <49BDC9B3.3020808@taltos.org> <20090316074709.xoymn3nx0gk8ggc4@mail.elegosoft.com> Message-ID: I don't see that Carson is on this email. Please build and ship m3core from current source. Specifically, m3core/src/unix/Common/Uconstants.c has: #define X(x) const int Uexec__##x = x; X(WNOHANG) it used to have just one underscore: #define X(x) const int Uexec_##x = x; X(WNOHANG) If it is really necessary, we could put both in for increased compat -- but in that case, might as well have left it with one underscore. As well, you can temporarily change it to whatever you find the value in /usr/include (1 on Linux/x86), or, depending on your code, 0 might be good. 0 is good if the thread waiting on a process is meant to block until the child process exits. Use of nohang historically in the cm3 code is only for the benefit of user threads -- it is inefficient and imho not important. I can imagine an app where one thread polls multiple child processes though, which might require the nohang. (I really like the Windows model where process, files, sockets, threads...all are waiting with the same functions...) > it's the 64 bit targets on Intel processors which are > rather new and unpolished. If you have particulars, please let me know. I admit I'm not using them..I'm nervous as to what my electricity bill would be if I actually left everything powered on and running the Tinderbox.. I know there is the thing..we should probe if /usr/lib64 exists and use if it so, else /usr/lib. > This reminds me that we should add cvsup as a cm3 project and include Yes, anything you can add to the "std" package set, please do. - Jay ---------------------------------------- > Date: Mon, 16 Mar 2009 07:47:09 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] cvsup and cm3 - drama galore! Any help for Uexec_WNOHANG? > > Quoting Carson Gaspar : > >> I want to end up with a working cvsup for our RHEL5 U4 x86_64 servers (a >> working 32-bit binary is fine...). >> >> So I tried building cm3 and ran into problems trying to bootstrap. The >> list archives said "use newer source". So I tried. And the latest >> snapshots failed to build. I saw a message complaining about the >> regression (sadly sans solution), so I grabbed source from CVS as of Jan >> 31, 2009. That built! >> >> So now I try building cvsup. Then I apply the cm3 patch and try again. >> Then I manually hack "SchedulerPOSIX" to "Scheduler" and try again >> (thank my lucky stars for Google!). So now I _almost_ have it building, >> but it fails on FSServerU.m3, complaining about an undefined reference >> to Uexec_WNOHANG. And here I sit, stumped. I see a C sourse file >> Uconstants.c in the cm3 distribution that looks like it _ought_ to >> define it, but obviously something is unhappy... >> >> When was the last time somebody successfully built cvsup with cm3 on >> Linux? I'll gladly bootstrap from some known good point, but I'd rather >> avoid doing a binary search to find a working compiler... > > It's not Linux, it's the 64 bit targets on Intel processors which are > rather new and unpolished. I don't think the WNOHANG problem is due to > that, though; I rather think it may have been `optimized away' during > a perhaps too rigorous code clean-up recently. > > Jay, could it be that this constant is acceidently missing in newer > sources? > > This reminds me that we should add cvsup as a cm3 project and include > it in our regression tests. I'll try to do that some time soon. > > Don't panic; we'll be able to get cvsup to compile ;-) > > Regards, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Mar 16 08:56:08 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 07:56:08 +0000 Subject: [M3devel] cvsup and cm3 - minor problems Any help for Uexec_WNOHANG? In-Reply-To: <20090316074709.xoymn3nx0gk8ggc4@mail.elegosoft.com> References: <49BDC9B3.3020808@taltos.org> <20090316074709.xoymn3nx0gk8ggc4@mail.elegosoft.com> Message-ID: [adding Carson this time] Please build and ship m3core from current source. Specifically, m3core/src/unix/Common/Uconstants.c has: #define X(x) const int Uexec__##x = x; X(WNOHANG) it used to have just one underscore: #define X(x) const int Uexec_##x = x; X(WNOHANG) If it is really necessary, we could put both in for increased compat -- but in that case, might as well have left it with one underscore. As well, you can temporarily change it to whatever you find the value in /usr/include (1 on Linux/x86), or, depending on your code, 0 might be good. 0 is good if the thread waiting on a process is meant to block until the child process exits. Use of nohang historically in the cm3 code is only for the benefit of user threads -- it is inefficient and imho not important. I can imagine an app where one thread polls multiple child processes though, which might require the nohang. (I really like the Windows model where process, files, sockets, threads...all are waiting with the same functions...) > it's the 64 bit targets on Intel processors which are > rather new and unpolished. If you have particulars, please let me know. I admit I'm not using them..I'm nervous as to what my electricity bill would be if I actually left everything powered on and running the Tinderbox.. I know there is the thing..we should probe if /usr/lib64 exists and use if it so, else /usr/lib. > This reminds me that we should add cvsup as a cm3 project and include Yes, anything you can add to the "std" package set, please do. - Jay > > > ---------------------------------------- >> Date: Mon, 16 Mar 2009 07:47:09 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com; jay.krell at cornell.edu >> Subject: Re: [M3devel] cvsup and cm3 - drama galore! Any help for Uexec_WNOHANG? >> >> Quoting Carson Gaspar : >> >>> I want to end up with a working cvsup for our RHEL5 U4 x86_64 servers (a >>> working 32-bit binary is fine...). >>> >>> So I tried building cm3 and ran into problems trying to bootstrap. The >>> list archives said "use newer source". So I tried. And the latest >>> snapshots failed to build. I saw a message complaining about the >>> regression (sadly sans solution), so I grabbed source from CVS as of Jan >>> 31, 2009. That built! >>> >>> So now I try building cvsup. Then I apply the cm3 patch and try again. >>> Then I manually hack "SchedulerPOSIX" to "Scheduler" and try again >>> (thank my lucky stars for Google!). So now I _almost_ have it building, >>> but it fails on FSServerU.m3, complaining about an undefined reference >>> to Uexec_WNOHANG. And here I sit, stumped. I see a C sourse file >>> Uconstants.c in the cm3 distribution that looks like it _ought_ to >>> define it, but obviously something is unhappy... >>> >>> When was the last time somebody successfully built cvsup with cm3 on >>> Linux? I'll gladly bootstrap from some known good point, but I'd rather >>> avoid doing a binary search to find a working compiler... >> >> It's not Linux, it's the 64 bit targets on Intel processors which are >> rather new and unpolished. I don't think the WNOHANG problem is due to >> that, though; I rather think it may have been `optimized away' during >> a perhaps too rigorous code clean-up recently. >> >> Jay, could it be that this constant is acceidently missing in newer >> sources? >> >> This reminds me that we should add cvsup as a cm3 project and include >> it in our regression tests. I'll try to do that some time soon. >> >> Don't panic; we'll be able to get cvsup to compile ;-) >> >> Regards, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> From jay.krell at cornell.edu Mon Mar 16 09:57:40 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 08:57:40 +0000 Subject: [M3devel] recent problems? In-Reply-To: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> References: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> Message-ID: Thanks. Here is another one. I found this testing moving PPC_DARWIN to "my headers". formsedit crashes during startup roughly more than half the times I start up, but not every time. The stack is always the same. I'll test it without my change. I think it'll happen either way, but I'll see. Yes, it recurs without my change, though I double check that my change is really undone. I'll have to dig into this. How does one get the code from CVS corresponding to a date? cvs upd -D ? I'll try that or something, see if I can find when things worked. I should also be able to try the mklib crashing scenario on other platforms. It normally doesn't run on other platforms. stubgen..if I'm ambitious, I can run in a loop on another platform. But I think just moving Cygwin off of pthreads will "fix" it and provide a cleaner base (not due to pthreads, but the Cygwin stuff). Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 [Switching to process 19583 thread 0x2643] 0x0031798c in ScrollerVBTClass__PaintViewWithShadows (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc rollerVBTClass.m3:325 325 VBT.PaintTint(v, r, v.shadow.bg); (gdb) bt #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI X/ScrollerVBTClass.m3:325 #1 0x0031766c in ScrollerVBTClass__PaintView (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV BTClass.m3:292 #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, M3_A0Kbc5_rgn=0xf0284778) at ../ src/lego/POSIX/ScrollerVBTClass.m3:693 #3 0x0031a590 in ScrollerVBTClass__Redisplay (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV BTClass.m3:706 #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../src/vbt/VBTClass.m3:367 #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/VBTRep.m3:601 #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../src/vbt/VBTRep.m3:606 #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) at ../src/thread/PTHREAD/ThreadP Thread.m3:531 #9 0x0132fb58 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr eadPThread.m3:508 #10 0x9002b908 in _pthread_body () (gdb) - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 16 Mar 2009 08:10:05 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > You might have structure sizes wrong and your stack will get shifted > around as the command line changes length. You get some data in a > structure wrong and then hit the wrong stack org and you might see > problems like this. > > I am not running things totally off of the head, so if the problem was > introduced recently it might only now be seen. > > On 16 Mar 2009, at 06:15, Jay wrote: > >> >> I'm seeing some problems lately. Maybe it is just me. >> Some of them I've had over a week (ie: before my (most) recent >> changes), >> some of them even if recently appeared I verified without my (most) >> recent changes. >> >> On Cygwin 1.5, mklib always crashes. I haven't been able to debug it. >> This has been over a week. >> I've had to stop using Cygwin for Modula-3 development on this >> machine. >> I have a good repro but hadn't had luck yet debugging it. >> Basically if I shorten the mklib command line (in the response >> file) substantially, no crash. >> There is a cut off somewhere. >> >> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >> hangs. >> It hangs nowhere else. >> This I verified occured without my recent changes. >> I only just in the past few days tried Cygwin 1.7. >> mklib works fine here. >> Of course since this is somewhat intermittent, maybe it isn't a new >> problem. >> >> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >> machines, >> though they do coexist ok on one machine. >> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >> binares >> apparently don't run on 1.5 -- at least not if they use assert(). >> 1.7 is a recent past or future release, a long time in the works, >> drops Win9x support, lots of good sounding changes. >> >> I should run m3tests more, maybe they will reveal the crash or the >> hang as well. >> >> On LINUXLIBC6 on one machine stubgen was crashing at least in one >> directory. >> But I think this stopped happening. >> >> Cygwin being broken pushes me to other platforms more, probably a >> good thing. >> I'm loathe to debug the hang. When it occurs I can't see any stacks >> in gdb. I can see in strace.. >> I think we are waiting for all the threads to suspend themselves. >> I'll probably try moving back to Win32 threads and see if it clears >> up. >> I know that's not great. >> There isn't a clear implied question and I know I should/need to >> look into these, >> but I also thought I shouldn't keep this to myself. I also >> understand the philosophy >> of stopping changes when there are problems, to stop further >> damage, but, of course, >> I'm very confident in my changes (always..), have been testing them >> on other platforms, >> and looking them over extra extra since I know of these other >> problems. >> >> I'm not sure any problem on Cygwin is worrisome really. >> I think the underlying code is kind of gnarly and I don't think >> anyone uses this platform, though people asked for it. >> But I did have a crash on LINUXLIBC6. >> >> - Jay > From jay.krell at cornell.edu Mon Mar 16 14:16:21 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 13:16:21 +0000 Subject: [M3devel] recent problems? In-Reply-To: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> References: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> Message-ID: mklib seems ok now, having started over with a new checkout, new build. Strange considering what I had already tried, this problem had been plaguing me over a week. stubgen doesn't hang with 1.5, will try 1.7 again/later. But formsedit still crashes during startup intermittently, and Cygwin X apps hang at startup. ugh. I know, I probably caused whatever problem.. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] recent problems? > Date: Mon, 16 Mar 2009 08:57:40 +0000 > > > Thanks. > > > Here is another one. > I found this testing moving PPC_DARWIN to "my headers". > formsedit crashes during startup roughly more than > half the times I start up, but not every time. > The stack is always the same. > I'll test it without my change. > I think it'll happen either way, but I'll see. > Yes, it recurs without my change, though I double > check that my change is really undone. > I'll have to dig into this. > > > How does one get the code from CVS corresponding to a date? > cvs upd -D ? > I'll try that or something, see if I can find when things worked. > > > I should also be able to try the mklib crashing scenario > on other platforms. It normally doesn't run on other platforms. > > > stubgen..if I'm ambitious, I can run in a loop on another platform. > But I think just moving Cygwin off of pthreads will "fix" it > and provide a cleaner base (not due to pthreads, but the Cygwin stuff). > > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 > [Switching to process 19583 thread 0x2643] > 0x0031798c in ScrollerVBTClass__PaintViewWithShadows (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc > rollerVBTClass.m3:325 > 325 VBT.PaintTint(v, r, v.shadow.bg); > (gdb) bt > #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI > X/ScrollerVBTClass.m3:325 > #1 0x0031766c in ScrollerVBTClass__PaintView (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV > BTClass.m3:292 > #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, M3_A0Kbc5_rgn=0xf0284778) at ../ > src/lego/POSIX/ScrollerVBTClass.m3:693 > #3 0x0031a590 in ScrollerVBTClass__Redisplay (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV > BTClass.m3:706 > #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../src/vbt/VBTClass.m3:367 > #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 > #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/VBTRep.m3:601 > #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../src/vbt/VBTRep.m3:606 > #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) at ../src/thread/PTHREAD/ThreadP > Thread.m3:531 > #9 0x0132fb58 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr > eadPThread.m3:508 > #10 0x9002b908 in _pthread_body () > (gdb) > > > > - Jay > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Mon, 16 Mar 2009 08:10:05 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] recent problems? >> >> You might have structure sizes wrong and your stack will get shifted >> around as the command line changes length. You get some data in a >> structure wrong and then hit the wrong stack org and you might see >> problems like this. >> >> I am not running things totally off of the head, so if the problem was >> introduced recently it might only now be seen. >> >> On 16 Mar 2009, at 06:15, Jay wrote: >> >>> >>> I'm seeing some problems lately. Maybe it is just me. >>> Some of them I've had over a week (ie: before my (most) recent >>> changes), >>> some of them even if recently appeared I verified without my (most) >>> recent changes. >>> >>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug it. >>> This has been over a week. >>> I've had to stop using Cygwin for Modula-3 development on this >>> machine. >>> I have a good repro but hadn't had luck yet debugging it. >>> Basically if I shorten the mklib command line (in the response >>> file) substantially, no crash. >>> There is a cut off somewhere. >>> >>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>> hangs. >>> It hangs nowhere else. >>> This I verified occured without my recent changes. >>> I only just in the past few days tried Cygwin 1.7. >>> mklib works fine here. >>> Of course since this is somewhat intermittent, maybe it isn't a new >>> problem. >>> >>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>> machines, >>> though they do coexist ok on one machine. >>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>> binares >>> apparently don't run on 1.5 -- at least not if they use assert(). >>> 1.7 is a recent past or future release, a long time in the works, >>> drops Win9x support, lots of good sounding changes. >>> >>> I should run m3tests more, maybe they will reveal the crash or the >>> hang as well. >>> >>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>> directory. >>> But I think this stopped happening. >>> >>> Cygwin being broken pushes me to other platforms more, probably a >>> good thing. >>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>> in gdb. I can see in strace.. >>> I think we are waiting for all the threads to suspend themselves. >>> I'll probably try moving back to Win32 threads and see if it clears >>> up. >>> I know that's not great. >>> There isn't a clear implied question and I know I should/need to >>> look into these, >>> but I also thought I shouldn't keep this to myself. I also >>> understand the philosophy >>> of stopping changes when there are problems, to stop further >>> damage, but, of course, >>> I'm very confident in my changes (always..), have been testing them >>> on other platforms, >>> and looking them over extra extra since I know of these other >>> problems. >>> >>> I'm not sure any problem on Cygwin is worrisome really. >>> I think the underlying code is kind of gnarly and I don't think >>> anyone uses this platform, though people asked for it. >>> But I did have a crash on LINUXLIBC6. >>> >>> - Jay >> From hosking at cs.purdue.edu Mon Mar 16 15:54:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 17 Mar 2009 01:54:34 +1100 Subject: [M3devel] recent problems? In-Reply-To: References: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> Message-ID: This is worrying as it seems some level of instability has been introduced by recent changes. mentor used to be fine. On 17 Mar 2009, at 00:16, Jay wrote: > > mklib seems ok now, having started over with a new checkout, new > build. > Strange considering what I had already tried, this problem had been > plaguing me over a week. > > > stubgen doesn't hang with 1.5, will try 1.7 again/later. > > > But formsedit still crashes during startup intermittently, > and Cygwin X apps hang at startup. > ugh. > I know, I probably caused whatever problem.. > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] recent problems? >> Date: Mon, 16 Mar 2009 08:57:40 +0000 >> >> >> Thanks. >> >> >> Here is another one. >> I found this testing moving PPC_DARWIN to "my headers". >> formsedit crashes during startup roughly more than >> half the times I start up, but not every time. >> The stack is always the same. >> I'll test it without my change. >> I think it'll happen either way, but I'll see. >> Yes, it recurs without my change, though I double >> check that my change is really undone. >> I'll have to dig into this. >> >> >> How does one get the code from CVS corresponding to a date? >> cvs upd -D ? >> I'll try that or something, see if I can find when things worked. >> >> >> I should also be able to try the mklib crashing scenario >> on other platforms. It normally doesn't run on other platforms. >> >> >> stubgen..if I'm ambitious, I can run in a loop on another platform. >> But I think just moving Cygwin off of pthreads will "fix" it >> and provide a cleaner base (not due to pthreads, but the Cygwin >> stuff). >> >> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >> [Switching to process 19583 thread 0x2643] >> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >> rollerVBTClass.m3:325 >> 325 VBT.PaintTint(v, r, v.shadow.bg); >> (gdb) bt >> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >> X/ScrollerVBTClass.m3:325 >> #1 0x0031766c in ScrollerVBTClass__PaintView >> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >> BTClass.m3:292 >> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >> M3_A0Kbc5_rgn=0xf0284778) at ../ >> src/lego/POSIX/ScrollerVBTClass.m3:693 >> #3 0x0031a590 in ScrollerVBTClass__Redisplay >> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >> BTClass.m3:706 >> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../ >> src/vbt/VBTClass.m3:367 >> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >> VBTRep.m3:601 >> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >> src/vbt/VBTRep.m3:606 >> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >> at ../src/thread/PTHREAD/ThreadP >> Thread.m3:531 >> #9 0x0132fb58 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >> eadPThread.m3:508 >> #10 0x9002b908 in _pthread_body () >> (gdb) >> >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] recent problems? >>> >>> You might have structure sizes wrong and your stack will get shifted >>> around as the command line changes length. You get some data in a >>> structure wrong and then hit the wrong stack org and you might see >>> problems like this. >>> >>> I am not running things totally off of the head, so if the problem >>> was >>> introduced recently it might only now be seen. >>> >>> On 16 Mar 2009, at 06:15, Jay wrote: >>> >>>> >>>> I'm seeing some problems lately. Maybe it is just me. >>>> Some of them I've had over a week (ie: before my (most) recent >>>> changes), >>>> some of them even if recently appeared I verified without my (most) >>>> recent changes. >>>> >>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>> it. >>>> This has been over a week. >>>> I've had to stop using Cygwin for Modula-3 development on this >>>> machine. >>>> I have a good repro but hadn't had luck yet debugging it. >>>> Basically if I shorten the mklib command line (in the response >>>> file) substantially, no crash. >>>> There is a cut off somewhere. >>>> >>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>> hangs. >>>> It hangs nowhere else. >>>> This I verified occured without my recent changes. >>>> I only just in the past few days tried Cygwin 1.7. >>>> mklib works fine here. >>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>> problem. >>>> >>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>> machines, >>>> though they do coexist ok on one machine. >>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>> binares >>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>> 1.7 is a recent past or future release, a long time in the works, >>>> drops Win9x support, lots of good sounding changes. >>>> >>>> I should run m3tests more, maybe they will reveal the crash or the >>>> hang as well. >>>> >>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>> directory. >>>> But I think this stopped happening. >>>> >>>> Cygwin being broken pushes me to other platforms more, probably a >>>> good thing. >>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>> in gdb. I can see in strace.. >>>> I think we are waiting for all the threads to suspend themselves. >>>> I'll probably try moving back to Win32 threads and see if it clears >>>> up. >>>> I know that's not great. >>>> There isn't a clear implied question and I know I should/need to >>>> look into these, >>>> but I also thought I shouldn't keep this to myself. I also >>>> understand the philosophy >>>> of stopping changes when there are problems, to stop further >>>> damage, but, of course, >>>> I'm very confident in my changes (always..), have been testing them >>>> on other platforms, >>>> and looking them over extra extra since I know of these other >>>> problems. >>>> >>>> I'm not sure any problem on Cygwin is worrisome really. >>>> I think the underlying code is kind of gnarly and I don't think >>>> anyone uses this platform, though people asked for it. >>>> But I did have a crash on LINUXLIBC6. >>>> >>>> - Jay >>> From mfmorss at aep.com Mon Mar 16 19:33:13 2009 From: mfmorss at aep.com (mfmorss at aep.com) Date: Mon, 16 Mar 2009 14:33:13 -0400 Subject: [M3devel] CM3 on Linux 64-bit Message-ID: I apologize in advance if this is not the right place to ask this. If I use CM3 on Linux 64-bit running on Intel multi-core chips (two quad core chips, actually), do I have a valid expectation that I will be able to implement concurrent multithreading? I tried to discover this on the website, and if it's there, I must have missed it. Thanks in advance. From jay.krell at cornell.edu Mon Mar 16 21:52:49 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 20:52:49 +0000 Subject: [M3devel] CM3 on Linux 64-bit In-Reply-To: References: Message-ID: Yes. The Modula-3 threading library is a thin wrapper over pthreads. Whatever level of concurrency your kernel and hardware can provide, the Modula-3 runtime will provide. (There is a non-default user-thread *option* for which the answer is "no", but it is not currently implemented on Linux/amd64 and doesn't work currently on any Linux. So again, definitely yes.) - Jay ---------------------------------------- > To: m3devel at elegosoft.com > From: mfmorss at aep.com > Date: Mon, 16 Mar 2009 14:33:13 -0400 > Subject: [M3devel] CM3 on Linux 64-bit > > I apologize in advance if this is not the right place to ask this. If I > use CM3 on Linux 64-bit running on Intel multi-core chips (two quad core > chips, actually), do I have a valid expectation that I will be able to > implement concurrent multithreading? > > I tried to discover this on the website, and if it's there, I must have > missed it. > > Thanks in advance. From jay.krell at cornell.edu Mon Mar 16 21:55:58 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 16 Mar 2009 20:55:58 +0000 Subject: [M3devel] recent problems? In-Reply-To: References: <89969B6B-7593-443B-A1CE-7BD9A5D8B63C@cs.purdue.edu> Message-ID: It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > From dabenavidesd at yahoo.es Tue Mar 17 01:14:35 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 16 Mar 2009 17:14:35 -0700 (PDT) Subject: [M3devel] recent problems? In-Reply-To: Message-ID: <434202.9613.qm@web24705.mail.ird.yahoo.com> Hi all: well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system. Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time. So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler). I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here. But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did? Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said. Thanks in advance --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: Re: [M3devel] recent problems? Para: "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 3:55 It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at .../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 17 03:47:10 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 02:47:10 +0000 Subject: [M3devel] recent problems? In-Reply-To: <434202.9613.qm@web24705.mail.ird.yahoo.com> References: <434202.9613.qm@web24705.mail.ird.yahoo.com> Message-ID: I'm making the system more safe, not less. The previous methodology was tedious, error prone, and didn't get any sort of checking. Whatever was declared in the *.i3 files was presumed correct. The linkage from the next layer to this layer gets the same amount of checking as it used. The link you point to shows people fixing things the same way as I am making them. unix/*.i3 must use <*EXTERNAL*> to declare C functions. That is what it did. That is what it does. Extend this out slightly to m3core/libm3. Same thing. The difference is whether or not those C functions are implemented right there, once, plain to see that they match the <*EXTERNAL*> declarations, or whether they are in a per-platform /usr/include and source tree somewhere, with tedious and error prone and per-platform verification as to if they are correct. As well as copy/pasting where there the "API" might be a macro. Really, I am making the system more safe, not less. There is no loss in checking but there is more obvious correctness by human inspection in what must be unsafe, one way or another. The result is also more portable. - Jay Date: Mon, 16 Mar 2009 17:14:35 -0700 From: dabenavidesd at yahoo.es To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] recent problems? Hi all: well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system. Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time. So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler). I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here. But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did? Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said. Thanks in advance --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: Re: [M3devel] recent problems? Para: "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 3:55 It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Mar 17 04:05:24 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 16 Mar 2009 20:05:24 -0700 (PDT) Subject: [M3devel] recent problems? In-Reply-To: Message-ID: <423325.54448.qm@web24703.mail.ird.yahoo.com> The problem is not your changes, the problem is that putting C code can't be checked by a type safe checking process: I do agree the goodness of your checks, which may get things better, but unfortunately you have seen the effects of the this changes, we can't have human checking to solve unhidden bugs. Compile type checking allows to discard problems in Modula-3 code and at least? a clue that something needs more checking in UNSAFE Modules or Interfaces. You have changed that we depend no more on cloned platform dependent .i3 files, but on C code which it slef depends on unsafe C platform dependent thirdparty libraries. That is the problem is not now on the Modula-3 source code but in the actual platform. I can't agree that is safer than it was before, nor because of the language, or you, but of the thid party code. Now we have more code just that it's no more Modula-3, it's C but yes, is lesser code (well forgeting about C preprocessor). I hope this is more clear of my ideas and any clue of what i am tryin to say here. Thanks for your comments. --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: RE: [M3devel] recent problems? Para: "Daniel (M3)" , "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 9:47 #yiv878206134 .hmmessage P { margin:0px;padding:0px;} #yiv878206134 { font-size:10pt;font-family:Verdana;} I'm making the system more safe, not less. ? ? The previous methodology was tedious, error prone, and didn't get any sort of checking. ? ? Whatever was declared in the *.i3 files was presumed correct. ? ? The linkage from the next layer to this layer gets the same amount of checking as it used. ? ? The link you point to shows people fixing things the same way as I am making them. ? ? unix/*.i3 must use <*EXTERNAL*> to declare C functions. That is what it did. That is what it does. Extend this out slightly to m3core/libm3. ?Same thing. The difference is whether or not those C functions are implemented right there, once, plain to see that they match the <*EXTERNAL*> declarations, or whether they are in a per-platform /usr/include and source tree somewhere, with tedious and error prone and per-platform verification as to if they are correct. As well as copy/pasting where there the "API" might be a macro. ? ? Really, I am making the system more safe, not less. There is no loss in checking but there is more obvious correctness by human inspection in what must be unsafe, one way or another. ? ? The result is also more portable. ? ? ?- Jay ? Date: Mon, 16 Mar 2009 17:14:35 -0700 From: dabenavidesd at yahoo.es To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] recent problems? Hi all: well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system. Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time. So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler). I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here. But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus..blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did? Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said. Thanks in advance --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: Re: [M3devel] recent problems? Para: "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 3:55 It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at .../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Mar 17 04:30:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 17 Mar 2009 14:30:35 +1100 Subject: [M3devel] recent problems? In-Reply-To: References: <434202.9613.qm@web24705.mail.ird.yahoo.com> Message-ID: Keep up the good work Jay! On 17 Mar 2009, at 13:47, Jay wrote: > I'm making the system more safe, not less. > > > The previous methodology was tedious, error prone, and didn't get > any sort of checking. > > > Whatever was declared in the *.i3 files was presumed correct. > > > The linkage from the next layer to this layer gets the same amount > of checking as it used. > > > The link you point to shows people fixing things the same way as I > am making them. > > > unix/*.i3 must use <*EXTERNAL*> to declare C functions. > That is what it did. That is what it does. > Extend this out slightly to m3core/libm3. > Same thing. > The difference is whether or not those C functions are implemented > right there, once, plain to see that they match the <*EXTERNAL*> > declarations, or whether they are in a per-platform /usr/include and > source tree somewhere, with tedious and error prone and per-platform > verification as to if they are correct. As well as copy/pasting > where there the "API" might be a macro. > > > Really, I am making the system more safe, not less. > There is no loss in checking but there is more obvious correctness > by human inspection in what must be unsafe, one way or another. > > > The result is also more portable. > > > - Jay > > Date: Mon, 16 Mar 2009 17:14:35 -0700 > From: dabenavidesd at yahoo.es > To: hosking at cs.purdue.edu; jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > Hi all: > well, I know more about the kind of work done recently, which I can > not just say is unsafe, but putting a layer of C code that obviously > is dependent of each Linux/Unix, I guess in the past this is not > always true, but having each Linux it's own headers and different > implementations makes more unstable the system. > Besides the type checking made by C Compiler is not checked at link > time, in contrast of Modula-3 that type checks whenever interfaces > are changed and checks on link time. > So if you put change in your C code doesn't mean that Modula-3 will > catch common silly but common true errors, like buffer overflows > that if not checked at run time will crash (almost always) at > runtime of a safe program, and it will not be safe (hidden code is > beyond the Modula-3 compiler). > I strongly support simplifying and factoring as much as possible, > but try to use what is there in Modula-3, not re-implementing in > another Language if possible at all. I know but even more, the idea > of having linking with C code on the kernel system calls allows to > protect from so called side effects of Kernel code. Memory > protection is exhausted here. > But when using true library user space system calls, this puts in a > dangerous side the untrusted code. Here I reclaim again not using > more that true system calls. I see that this started to be harder > with AMD64 or x86_64 current platforms, so further development may > be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html > about ezm3 related problems, is this supposed to be handled in Cm3 > like the same they did? > Jay and all seem to do the better job they can, but I don't want to > miss the opportunity to say this if I may. I will tell you later > more about the type system If this it is useful to be said. > > Thanks in advance > > --- El lun, 16/3/09, Jay escribi?: > De: Jay > Asunto: Re: [M3devel] recent problems? > Para: "Tony" > CC: "m3devel" > Fecha: lunes, 16 marzo, 2009 3:55 > > It's ok on LINUXLIBC6 with the "new headers" but > I believe PPC_DARWIN problem caused by them so > backed out pending debugging. > This one looks easy to solve, though my time > is scarser next week or two. > > I should have maybe considered: > "new headers" used on a number of Linux systems already > but no Darwin systems yet > > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Tue, 17 Mar 2009 01:54:34 +1100 > > CC: > m3devel at elegosoft.com > > Subject: Re: [M3devel] recent problems? > > > > This is worrying as it seems some level of instability has been > > introduced by recent changes. mentor used to be fine. > > > > On 17 Mar 2009, at 00:16, Jay wrote: > > > >> > >> mklib seems ok now, having started over with a new checkout, new > >> build. > >> Strange considering what I had already tried, this problem had been > >> plaguing me over a week. > >> > >> > >> stubgen doesn't hang with 1.5, will try 1.7 again/later. > >> > >> > >> But formsedit still crashes during startup intermittently, > >> and Cygwin X apps hang at startup. > >> ugh. > >> I know, I probably caused whatever problem.. > >> > >> > >> - Jay > >> > >> > >> > >> ---------------------------------------- > >>> From: > jay.krell at cornell.edu > >>> To: hosking at cs.purdue.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: RE: [M3devel] recent problems? > >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 > >>> > >>> > >>> Thanks. > >>> > >>> > >>> Here is another one. > >>> I found this testing moving PPC_DARWIN to "my headers". > >>> formsedit crashes during startup roughly more than > >>> half the times I start up, but not every time. > >>> The stack is always the same. > >>> I'll test it without my change. > >>> I think it'll happen either way, but I'll see. > >>> Yes, it recurs without my change, though I double > >>> check that my change is really undone. > >>> I'll have to dig into this. > >>> > >>> > >>> How does one get the code from CVS corresponding to a > date? > >>> cvs upd -D ? > >>> I'll try that or something, see if I can find when things > worked. > >>> > >>> > >>> I should also be able to try the mklib crashing scenario > >>> on other platforms. It normally doesn't run on other > platforms. > >>> > >>> > >>> stubgen..if I'm ambitious, I can run in a loop on another > platform. > >>> But I think just moving Cygwin off of pthreads will > "fix" it > >>> and provide a cleaner base (not due to pthreads, but the Cygwin > >>> stuff). > >>> > >>> > >>> Program received signal EXC_BAD_ACCESS, Could not access memory. > >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 > >>> [Switching to process 19583 thread 0x2643] > >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows > >>> (M3_Ao3CED_v=0x1f1eef4) at > ../src/lego/POSIX/Sc > >>> rollerVBTClass.m3:325 > >>> 325 VBT.PaintTint(v, r, v.shadow.bg); > >>> (gdb) bt > >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows > >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI > >>> X/ScrollerVBTClass.m3:325 > >>> #1 0x0031766c in ScrollerVBTClass__PaintView > >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV > >>> BTClass.m3:292 > >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, > >>> M3_A0Kbc5_rgn=0xf0284778) at ../ > >>> src/lego/POSIX/ScrollerVBTClass.m3:693 > >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay > >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV > >>> BTClass.m3:706 > >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at > ../ > >>> src/vbt/VBTClass.m3:367 > >>> > #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 > >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ > >>> VBTRep.m3:601 > >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ > >>> src/vbt/VBTRep.m3:606 > >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) > >>> at ../src/thread/PTHREAD/ThreadP > >>> Thread.m3:531 > >>> #9 0x0132fb58 in ThreadPThread__ThreadBase > >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr > >>> eadPThread.m3:508 > >>> #10 0x9002b908 in _pthread_body () > >>> (gdb) > >>> > >>> > >>> > >>> - Jay > >>> > >>> > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> To: > jay.krell at cornell.edu > >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] recent problems? > >>>> > >>>> You might have structure sizes wrong and your stack will get > shifted > >>>> around as the command line changes length. You get some data > in a > >>>> structure wrong and then hit the wrong stack org and you might > see > >>>> problems like this. > >>>> > >>>> I am not running things totally off of the head, so if the > problem > >>>> was > >>>> introduced recently it might only now be seen. > >>>> > >>>> On 16 Mar 2009, at 06:15, Jay wrote: > >>>> > >>>>> > >>>>> I'm seeing some problems lately. Maybe it is just me. > >>>>> Some of them I've had over > a week (ie: before my > (most) recent > >>>>> changes), > >>>>> some of them even if recently appeared I verified without > my (most) > >>>>> recent changes. > >>>>> > >>>>> On Cygwin 1.5, mklib always crashes. I haven't been > able to debug > >>>>> it. > >>>>> This has been over a week. > >>>>> I've had to stop using Cygwin for Modula-3 development > on this > >>>>> machine. > >>>>> I have a good repro but hadn't had luck yet debugging > it. > >>>>> Basically if I shorten the mklib command line (in the > response > >>>>> file) substantially, no crash. > >>>>> There is a cut off somewhere. > >>>>> > >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but > not always > >>>>> > hangs. > >>>>> It hangs nowhere else. > >>>>> This I verified occured without my recent changes. > >>>>> I only just in the past few days tried Cygwin 1.7. > >>>>> mklib works fine here. > >>>>> Of course since this is somewhat intermittent, maybe it > isn't a new > >>>>> problem. > >>>>> > >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine > each, separate > >>>>> machines, > >>>>> though they do coexist ok on one machine. > >>>>> 1.7 seemed much faster (on an unimpressive machine), > though 1.7 > >>>>> binares > >>>>> apparently don't run on 1.5 -- at least not if they > use assert(). > >>>>> 1.7 is a recent past or future release, a long time in the > works, > >>>>> drops Win9x support, lots of good > sounding changes. > >>>>> > >>>>> I should run m3tests more, maybe they will reveal the > crash or the > >>>>> hang as well. > >>>>> > >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least > in one > >>>>> directory. > >>>>> But I think this stopped happening. > >>>>> > >>>>> Cygwin being broken pushes me to other platforms more, > probably a > >>>>> good thing. > >>>>> I'm loathe to debug the hang. When it occurs I > can't see any stacks > >>>>> in gdb. I can see in strace.. > >>>>> I think we are waiting for all the threads to suspend > themselves. > >>>>> I'll probably try moving back to Win32 threads and see > if it clears > >>>>> up. > >>>>> I know that's not > great. > >>>>> There isn't a clear implied question and I know I > should/need to > >>>>> look into these, > >>>>> but I also thought I shouldn't keep this to myself. I > also > >>>>> understand the philosophy > >>>>> of stopping changes when there are problems, to stop > further > >>>>> damage, but, of course, > >>>>> I'm very confident in my changes (always..), have been > testing them > >>>>> on other platforms, > >>>>> and looking them over extra extra since I know of these > other > >>>>> problems. > >>>>> > >>>>> I'm not sure any problem on Cygwin is worrisome > really. > >>>>> I think the underlying code is kind of gnarly and I > don't think > >>>>> anyone uses this platform, though people asked for > it. > >>>>> But I did have a crash on LINUXLIBC6. > >>>>> > >>>>> - Jay > >>>> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 17 08:10:35 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 07:10:35 +0000 Subject: [M3devel] recent problems? In-Reply-To: <423325.54448.qm@web24703.mail.ird.yahoo.com> References: <423325.54448.qm@web24703.mail.ird.yahoo.com> Message-ID: Daniel, I do not understand. We were already depending on the underlying code. Now we also have thin C wrappers and a little of checking by the C compiler. Where before we had no checking. I will admit I feel little hesitation to add more C code. I am really fluent and comfortable in C and am well aware of its dangers and how to avoid them. But..well..I need more justification than "because I can". I should add, btw, that that link suggests going a little beyond what I have done. I have a few ad-hoc methodologies/goals. Mainly "remove structs" and "remove constant #defines" (or wrap them). However, "remove all types" is not a goal. int remains, among others. Where there is something "as simple as" int foo(int); I have held back and just left the direct: <*EXTERNAL*> PROCEDURE foo(int):int; however that link suggests that /everything/ should be wrapped. It is easy to do, just: Interface.i3 <*EXTERNAL Interface__Foo*> PROCEDURE foo(int):int: Interface.c: int Interface__Foo(int a) { return Foo(a); } Usually this does nothing but introduce a jmp or an unoptimized prolog/call/epilog. (It can also help in getting callstacks and debugging, though that is a flawed argument.) However if foo is a macro, or some fancy inline function (more common these days), it could be a useful transform. (Look at how stat works..) I am interested in what people think here -- on the idea of "wrapping everything". There isn't a lot of this stuff left, so maybe we should go ahead and wrap it. Hey, actually, this will help with the "remains" -- the time stuff esp. I can hardcode time_t et. al. as long and go through thin wrappers. Sometimes I strive to wrap at a higher level, but that isn't necessary. This might be what you are alluding to, and has been on my mind a while anyway; I am sympathetic to the idea of eliminating C runtime dependencies and making direct kernel calls, at least on Linux. It is common on Linux/ARM systems to have uclibc instead of glibc. glibc is deemed "bloated" in some circles. Our binaries were not and are not portable to these systems. If we don't make this change, we are headed toward platforms that are more than architecture_kernel and instead architecture_kernel_cruntime -- ARM_LINUX_GLIBC, ARM_LINUX_UCLIBC, but it's worse than actually, ARM_LINUX_OLDABI_GLIBC, ARM_LINUX_OLDABI_UCLIBC, ARM_LINUX_UCLIBC, ARM_LINUX_GLIBC. I'd like to imagine "oldabi" is old and irrelevant, but I have such a system -- oldabi/uclibc -- the Western Digital MyBook "World Edition" is a viable target for Modula-3, on my list..though things are advancing..I have an $80 PogoPlug on the way, it might be much more performant..also, you could probably statically link to "any" C runtime, given our light usage.. "dietlibc" is another option, though I had trouble using it..and it seems a little too non-mainstream for me. "newlib" is also an option. But: This kind of devolves to: "Hey Tony, can you look into the Linux kernel 'futex' and 'clone' stuff et. al. and implement the Modula-3 threading library on top of it?" (Or anyone else?) That's not the whole story though. There'd still be stat, open, and socket stuff. But I think threading the main difficulty. I'm pretty sure this viable -- that the Modula-3 runtime is "thick enough", that anyone who maintains it (Tony; not necessarily me) is capable of implementing reasonable threading "on top of almost anything". - Jay Date: Mon, 16 Mar 2009 20:05:24 -0700 From: dabenavidesd at yahoo.es Subject: RE: [M3devel] recent problems? To: hosking at cs.purdue.edu; jay.krell at CORNELL.EDU CC: m3devel at elegosoft.com The problem is not your changes, the problem is that putting C code can't be checked by a type safe checking process: I do agree the goodness of your checks, which may get things better, but unfortunately you have seen the effects of the this changes, we can't have human checking to solve unhidden bugs. Compile type checking allows to discard problems in Modula-3 code and at least a clue that something needs more checking in UNSAFE Modules or Interfaces. You have changed that we depend no more on cloned platform dependent .i3 files, but on C code which it slef depends on unsafe C platform dependent thirdparty libraries. That is the problem is not now on the Modula-3 source code but in the actual platform. I can't agree that is safer than it was before, nor because of the language, or you, but of the thid party code. Now we have more code just that it's no more Modula-3, it's C but yes, is lesser code (well forgeting about C preprocessor). I hope this is more clear of my ideas and any clue of what i am tryin to say here. Thanks for your comments. --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: RE: [M3devel] recent problems? Para: "Daniel (M3)" , "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 9:47 I'm making the system more safe, not less. The previous methodology was tedious, error prone, and didn't get any sort of checking. Whatever was declared in the *.i3 files was presumed correct. The linkage from the next layer to this layer gets the same amount of checking as it used. The link you point to shows people fixing things the same way as I am making them. unix/*.i3 must use <*EXTERNAL*> to declare C functions. That is what it did. That is what it does. Extend this out slightly to m3core/libm3. Same thing. The difference is whether or not those C functions are implemented right there, once, plain to see that they match the <*EXTERNAL*> declarations, or whether they are in a per-platform /usr/include and source tree somewhere, with tedious and error prone and per-platform verification as to if they are correct. As well as copy/pasting where there the "API" might be a macro. Really, I am making the system more safe, not less. There is no loss in checking but there is more obvious correctness by human inspection in what must be unsafe, one way or another. The result is also more portable. - Jay Date: Mon, 16 Mar 2009 17:14:35 -0700 From: dabenavidesd at yahoo.es To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] recent problems? Hi all: well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system. Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time. So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler). I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here. But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did? Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said. Thanks in advance --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: Re: [M3devel] recent problems? Para: "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 3:55 It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone.. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 17 08:22:50 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 07:22:50 +0000 Subject: [M3devel] recent problems? In-Reply-To: <423325.54448.qm@web24703.mail.ird.yahoo.com> References: <423325.54448.qm@web24703.mail.ird.yahoo.com> Message-ID: Truncated again. Maybe a good thing. (But do try to wade through, there are a few "new questions" -- 1) that link suggests going further with the wrapping. What do folks think? There's so little left to do, and it would provide a little value, so I am sympathetic to it..but it should probably be automated, now that I think about the actual volume 2) Tony, can you implement Modua-3 on top of Linux kernel futex/clone? That might address Daniel's point, and give us portability across C runtimes, such as Linux/ARM/uclibc and Linux/ARM/glibc; I have a Linux/ARM/uclibc system.). Daniel, ok, is the choice: "some code with no checking" vs. "more code with a little checking" and, depending on "more vs. some". and "no vs. little", you could argue that "some with no" is better? Agreed, it's simple math, but I think in this case we are better with "more code with a little checking". "It depends on the coefficients." Again, I am confident in my C programming..having written thousands of lines in the past few months.. - Jay From: jay.krell at cornell.edu To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] recent problems? Date: Tue, 17 Mar 2009 07:10:35 +0000 Daniel, I do not understand. We were already depending on the underlying code. Now we also have thin C wrappers and a little of checking by the C compiler. Where before we had no checking. I will admit I feel little hesitation to add more C code. I am really fluent and comfortable in C and am well aware of its dangers and how to avoid them. But..well..I need more justification than "because I can". I should add, btw, that that link suggests going a little beyond what I have done. I have a few ad-hoc methodologies/goals. Mainly "remove structs" and "remove constant #defines" (or wrap them). However, "remove all types" is not a goal. int remains, among others. Where there is something "as simple as" int foo(int); I have held back and just left the direct: <*EXTERNAL*> PROCEDURE foo(int):int; however that link suggests that /everything/ should be wrapped. It is easy to do, just: Interface.i3 <*EXTERNAL Interface__Foo*> PROCEDURE foo(int):int: Interface.c: int Interface__Foo(int a) { return Foo(a); } Usually this does nothing but introduce a jmp or an unoptimized prolog/call/epilog. (It can also help in getting callstacks and debugging, though that is a flawed argument.) However if foo is a macro, or some fancy inline function (more common these days), it could be a useful transform. (Look at how stat works..) I am interested in what people think here -- on the idea of "wrapping everything". There isn't a lot of this stuff left, so maybe we should go ahead and wrap it. Hey, actually, this will help with the "remains" -- the time stuff esp. I can hardcode time_t et. al. as long and go through thin wrappers. Sometimes I strive to wrap at a higher level, but that isn't necessary. This might be what you are alluding to, and has been on my mind a while anyway; I am sympathetic to the idea of eliminating C runtime dependencies and making direct kernel calls, at least on Linux. It is common on Linux/ARM systems to have uclibc instead of glibc. glibc is deemed "bloated" in some circles. Our binaries were not and are not portable to these systems. If we don't make this change, we are headed toward platforms that are more than architecture_kernel and instead architecture_kernel_cruntime -- ARM_LINUX_GLIBC, ARM_LINUX_UCLIBC, but it's worse than actually, ARM_LINUX_OLDABI_GLIBC, ARM_LINUX_OLDABI_UCLIBC, ARM_LINUX_UCLIBC, ARM_LINUX_GLIBC. I'd like to imagine "oldabi" is old and irrelevant, but I have such a system -- oldabi/uclibc -- the Western Digital MyBook "World Edition" is a viable target for Modula-3, on my list..though things are advancing..I have an $80 PogoPlug on the way, it might be much more performant..also, you could probably statically link to "any" C runtime, given our light usage.. "dietlibc" is another option, though I had trouble using it..and it seems a little too non-mainstream for me. "newlib" is also an option. But: This kind of devolves to: "Hey Tony, can you look into the Linux kernel 'futex' and 'clone' stuff et. al. and implement the Modula-3 threading library on top of it?" (Or anyone else?) That's not the whole story though. There'd still be stat, open, and socket stuff. But I think threading the main difficulty. I'm pretty sure this viable -- that the Modula-3 runtime is "thick enough", that anyone who maintains it (Tony; not necessarily me) is capable of implementing reasonable threading "on top of almost anything". - Jay Date: Mon, 16 Mar 2009 20:05:24 -0700 From: dabenavidesd at yahoo.es Subject: RE: [M3devel] recent problems? To: hosking at cs.purdue.edu; jay.krell at CORNELL.EDU CC: m3devel at elegosoft.com The problem is not your changes, the problem is that putting C code can't be checked by a type safe checking process: I do agree the goodness of your checks, which may get things better, but unfortunately you have seen the effects of the this changes, we can't have human checking to solve unhidden bugs. Compile type checking allows to discard problems in Modula-3 code and at least a clue that something needs more checking in UNSAFE Modules or Interfaces. You have changed that we depend no more on cloned platform dependent .i3 files, but on C code which it slef depends on unsafe C platform dependent thirdparty libraries. That is the problem is not now on the Modula-3 source code but in the actual platform. I can't agree that is safer than it was before, nor because of the language, or you, but of the thid party code. Now we have more code just that it's no more Modula-3, it's C but yes, is lesser code (well forgeting about C preprocessor). I hope this is more clear of my ideas and any clue of what i am tryin to say here. Thanks for your comments. --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: RE: [M3devel] recent problems? Para: "Daniel (M3)" , "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 9:47 I'm making the system more safe, not less. The previous methodology was tedious, error prone, and didn't get any sort of checking. Whatever was declared in the *.i3 files was presumed correct. The linkage from the next layer to this layer gets the same amount of checking as it used. The link you point to shows people fixing things the same way as I am making them. unix/*.i3 must use <*EXTERNAL*> to declare C functions. That is what it did. That is what it does. Extend this out slightly to m3core/libm3. Same thing. The difference is whether or not those C functions are implemented right there, once, plain to see that they match the <*EXTERNAL*> declarations, or whether they are in a per-platform /usr/include and source tree somewhere, with tedious and error prone and per-platform verification as to if they are correct. As well as copy/pasting where there the "API" might be a macro. Really, I am making the system more safe, not less. There is no loss in checking but there is more obvious correctness by human inspection in what must be unsafe, one way or another. The result is also more portable. - Jay Date: Mon, 16 Mar 2009 17:14:35 -0700 From: dabenavidesd at yahoo.es To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] recent problems? Hi all: well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system. Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time. So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler). I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here. But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did? Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said. Thanks in advance --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: Re: [M3devel] recent problems? Para: "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 3:55 It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone.. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 17 08:32:54 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 07:32:54 +0000 Subject: [M3devel] FW: recent problems? In-Reply-To: <423325.54448.qm@web24703.mail.ird.yahoo.com> References: <423325.54448.qm@web24703.mail.ird.yahoo.com> Message-ID: [truncated again, I should have known -- need to forward instead of replyall] From: jay.krell at cornell.edu To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] recent problems? Date: Tue, 17 Mar 2009 07:22:50 +0000 Truncated again. Maybe a good thing. (But do try to wade through, there are a few "new questions" -- 1) that link suggests going further with the wrapping. What do folks think? There's so little left to do, and it would provide a little value, so I am sympathetic to it..but it should probably be automated, now that I think about the actual volume 2) Tony, can you implement Modua-3 on top of Linux kernel futex/clone? That might address Daniel's point, and give us portability across C runtimes, such as Linux/ARM/uclibc and Linux/ARM/glibc; I have a Linux/ARM/uclibc system.). Daniel, ok, is the choice: "some code with no checking" vs. "more code with a little checking" and, depending on "more vs. some". and "no vs. little", you could argue that "some with no" is better? Agreed, it's simple math, but I think in this case we are better with "more code with a little checking". "It depends on the coefficients." Again, I am confident in my C programming..having written thousands of lines in the past few months.. - Jay From: jay.krell at cornell.edu To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] recent problems? Date: Tue, 17 Mar 2009 07:10:35 +0000 Daniel, I do not understand. We were already depending on the underlying code. Now we also have thin C wrappers and a little of checking by the C compiler. Where before we had no checking. I will admit I feel little hesitation to add more C code. I am really fluent and comfortable in C and am well aware of its dangers and how to avoid them. But..well..I need more justification than "because I can". I should add, btw, that that link suggests going a little beyond what I have done. I have a few ad-hoc methodologies/goals. Mainly "remove structs" and "remove constant #defines" (or wrap them). However, "remove all types" is not a goal. int remains, among others. Where there is something "as simple as" int foo(int); I have held back and just left the direct: <*EXTERNAL*> PROCEDURE foo(int):int; however that link suggests that /everything/ should be wrapped. It is easy to do, just: Interface.i3 <*EXTERNAL Interface__Foo*> PROCEDURE foo(int):int: Interface.c: int Interface__Foo(int a) { return Foo(a); } Usually this does nothing but introduce a jmp or an unoptimized prolog/call/epilog. (It can also help in getting callstacks and debugging, though that is a flawed argument.) However if foo is a macro, or some fancy inline function (more common these days), it could be a useful transform. (Look at how stat works..) I am interested in what people think here -- on the idea of "wrapping everything". There isn't a lot of this stuff left, so maybe we should go ahead and wrap it. Hey, actually, this will help with the "remains" -- the time stuff esp. I can hardcode time_t et. al. as long and go through thin wrappers. Sometimes I strive to wrap at a higher level, but that isn't necessary. This might be what you are alluding to, and has been on my mind a while anyway; I am sympathetic to the idea of eliminating C runtime dependencies and making direct kernel calls, at least on Linux. It is common on Linux/ARM systems to have uclibc instead of glibc. glibc is deemed "bloated" in some circles. Our binaries were not and are not portable to these systems. If we don't make this change, we are headed toward platforms that are more than architecture_kernel and instead architecture_kernel_cruntime -- ARM_LINUX_GLIBC, ARM_LINUX_UCLIBC, but it's worse than actually, ARM_LINUX_OLDABI_GLIBC, ARM_LINUX_OLDABI_UCLIBC, ARM_LINUX_UCLIBC, ARM_LINUX_GLIBC. I'd like to imagine "oldabi" is old and irrelevant, but I have such a system -- oldabi/uclibc -- the Western Digital MyBook "World Edition" is a viable target for Modula-3, on my list..though things are advancing..I have an $80 PogoPlug on the way, it might be much more performant..also, you could probably statically link to "any" C runtime, given our light usage.. "dietlibc" is another option, though I had trouble using it..and it seems a little too non-mainstream for me. "newlib" is also an option. But: This kind of devolves to: "Hey Tony, can you look into the Linux kernel 'futex' and 'clone' stuff et. al. and implement the Modula-3 threading library on top of it?" (Or anyone else?) That's not the whole story though. There'd still be stat, open, and socket stuff. But I think threading the main difficulty. I'm pretty sure this viable -- that the Modula-3 runtime is "thick enough", that anyone who maintains it (Tony; not necessarily me) is capable of implementing reasonable threading "on top of almost anything". - Jay Date: Mon, 16 Mar 2009 20:05:24 -0700 From: dabenavidesd at yahoo.es Subject: RE: [M3devel] recent problems? To: hosking at cs.purdue.edu; jay.krell at CORNELL.EDU CC: m3devel at elegosoft.com The problem is not your changes, the problem is that putting C code can't be checked by a type safe checking process: I do agree the goodness of your checks, which may get things better, but unfortunately you have seen the effects of the this changes, we can't have human checking to solve unhidden bugs. Compile type checking allows to discard problems in Modula-3 code and at least a clue that something needs more checking in UNSAFE Modules or Interfaces. You have changed that we depend no more on cloned platform dependent .i3 files, but on C code which it slef depends on unsafe C platform dependent thirdparty libraries. That is the problem is not now on the Modula-3 source code but in the actual platform. I can't agree that is safer than it was before, nor because of the language, or you, but of the thid party code. Now we have more code just that it's no more Modula-3, it's C but yes, is lesser code (well forgeting about C preprocessor). I hope this is more clear of my ideas and any clue of what i am tryin to say here. Thanks for your comments. --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: RE: [M3devel] recent problems? Para: "Daniel (M3)" , "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 9:47 I'm making the system more safe, not less. The previous methodology was tedious, error prone, and didn't get any sort of checking. Whatever was declared in the *.i3 files was presumed correct. The linkage from the next layer to this layer gets the same amount of checking as it used. The link you point to shows people fixing things the same way as I am making them. unix/*.i3 must use <*EXTERNAL*> to declare C functions. That is what it did. That is what it does. Extend this out slightly to m3core/libm3. Same thing. The difference is whether or not those C functions are implemented right there, once, plain to see that they match the <*EXTERNAL*> declarations, or whether they are in a per-platform /usr/include and source tree somewhere, with tedious and error prone and per-platform verification as to if they are correct. As well as copy/pasting where there the "API" might be a macro. Really, I am making the system more safe, not less. There is no loss in checking but there is more obvious correctness by human inspection in what must be unsafe, one way or another. The result is also more portable. - Jay Date: Mon, 16 Mar 2009 17:14:35 -0700 From: dabenavidesd at yahoo.es To: hosking at cs.purdue.edu; jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] recent problems? Hi all: well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system. Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time. So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler). I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here. But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did? Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said. Thanks in advance --- El lun, 16/3/09, Jay escribi?: De: Jay Asunto: Re: [M3devel] recent problems? Para: "Tony" CC: "m3devel" Fecha: lunes, 16 marzo, 2009 3:55 It's ok on LINUXLIBC6 with the "new headers" but I believe PPC_DARWIN problem caused by them so backed out pending debugging. This one looks easy to solve, though my time is scarser next week or two. I should have maybe considered: "new headers" used on a number of Linux systems already but no Darwin systems yet - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 17 Mar 2009 01:54:34 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent problems? > > This is worrying as it seems some level of instability has been > introduced by recent changes. mentor used to be fine. > > On 17 Mar 2009, at 00:16, Jay wrote: > >> >> mklib seems ok now, having started over with a new checkout, new >> build. >> Strange considering what I had already tried, this problem had been >> plaguing me over a week. >> >> >> stubgen doesn't hang with 1.5, will try 1.7 again/later. >> >> >> But formsedit still crashes during startup intermittently, >> and Cygwin X apps hang at startup. >> ugh. >> I know, I probably caused whatever problem.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] recent problems? >>> Date: Mon, 16 Mar 2009 08:57:40 +0000 >>> >>> >>> Thanks. >>> >>> >>> Here is another one. >>> I found this testing moving PPC_DARWIN to "my headers". >>> formsedit crashes during startup roughly more than >>> half the times I start up, but not every time. >>> The stack is always the same. >>> I'll test it without my change. >>> I think it'll happen either way, but I'll see. >>> Yes, it recurs without my change, though I double >>> check that my change is really undone.. >>> I'll have to dig into this. >>> >>> >>> How does one get the code from CVS corresponding to a date? >>> cvs upd -D ? >>> I'll try that or something, see if I can find when things worked. >>> >>> >>> I should also be able to try the mklib crashing scenario >>> on other platforms. It normally doesn't run on other platforms. >>> >>> >>> stubgen..if I'm ambitious, I can run in a loop on another platform. >>> But I think just moving Cygwin off of pthreads will "fix" it >>> and provide a cleaner base (not due to pthreads, but the Cygwin >>> stuff). >>> >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 >>> [Switching to process 19583 thread 0x2643] >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/Sc >>> rollerVBTClass.m3:325 >>> 325 VBT.PaintTint(v, r, v.shadow.bg); >>> (gdb) bt >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI >>> X/ScrollerVBTClass.m3:325 >>> #1 0x0031766c in ScrollerVBTClass__PaintView >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:292 >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4, >>> M3_A0Kbc5_rgn=0xf0284778) at ../ >>> src/lego/POSIX/ScrollerVBTClass.m3:693 >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV >>> BTClass.m3:706 >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at ../ >>> src/vbt/VBTClass.m3:367 >>> #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652 >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/ >>> VBTRep.m3:601 >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../ >>> src/vbt/VBTRep.m3:606 >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940) >>> at ../src/thread/PTHREAD/ThreadP >>> Thread.m3:531 >>> #9 0x0132fb58 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr >>> eadPThread.m3:508 >>> #10 0x9002b908 in _pthread_body () >>> (gdb) >>> >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] recent problems? >>>> >>>> You might have structure sizes wrong and your stack will get shifted >>>> around as the command line changes length. You get some data in a >>>> structure wrong and then hit the wrong stack org and you might see >>>> problems like this. >>>> >>>> I am not running things totally off of the head, so if the problem >>>> was >>>> introduced recently it might only now be seen. >>>> >>>> On 16 Mar 2009, at 06:15, Jay wrote: >>>> >>>>> >>>>> I'm seeing some problems lately. Maybe it is just me. >>>>> Some of them I've had over a week (ie: before my (most) recent >>>>> changes), >>>>> some of them even if recently appeared I verified without my (most) >>>>> recent changes. >>>>> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been able to debug >>>>> it. >>>>> This has been over a week. >>>>> I've had to stop using Cygwin for Modula-3 development on this >>>>> machine. >>>>> I have a good repro but hadn't had luck yet debugging it. >>>>> Basically if I shorten the mklib command line (in the response >>>>> file) substantially, no crash. >>>>> There is a cut off somewhere. >>>>> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but not always >>>>> hangs. >>>>> It hangs nowhere else. >>>>> This I verified occured without my recent changes. >>>>> I only just in the past few days tried Cygwin 1.7. >>>>> mklib works fine here. >>>>> Of course since this is somewhat intermittent, maybe it isn't a new >>>>> problem. >>>>> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine each, separate >>>>> machines, >>>>> though they do coexist ok on one machine. >>>>> 1.7 seemed much faster (on an unimpressive machine), though 1.7 >>>>> binares >>>>> apparently don't run on 1.5 -- at least not if they use assert(). >>>>> 1.7 is a recent past or future release, a long time in the works, >>>>> drops Win9x support, lots of good sounding changes. >>>>> >>>>> I should run m3tests more, maybe they will reveal the crash or the >>>>> hang as well. >>>>> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least in one >>>>> directory. >>>>> But I think this stopped happening. >>>>> >>>>> Cygwin being broken pushes me to other platforms more, probably a >>>>> good thing. >>>>> I'm loathe to debug the hang. When it occurs I can't see any stacks >>>>> in gdb. I can see in strace.. >>>>> I think we are waiting for all the threads to suspend themselves. >>>>> I'll probably try moving back to Win32 threads and see if it clears >>>>> up. >>>>> I know that's not great. >>>>> There isn't a clear implied question and I know I should/need to >>>>> look into these, >>>>> but I also thought I shouldn't keep this to myself. I also >>>>> understand the philosophy >>>>> of stopping changes when there are problems, to stop further >>>>> damage, but, of course, >>>>> I'm very confident in my changes (always..), have been testing them >>>>> on other platforms, >>>>> and looking them over extra extra since I know of these other >>>>> problems. >>>>> >>>>> I'm not sure any problem on Cygwin is worrisome really. >>>>> I think the underlying code is kind of gnarly and I don't think >>>>> anyone uses this platform, though people asked for it. >>>>> But I did have a crash on LINUXLIBC6. >>>>> >>>>> - Jay >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 17 08:42:48 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 07:42:48 +0000 Subject: [M3devel] off topic: buy an Alpha? Message-ID: mailing list abuse: Anyone want to buy any Alphas? I might be stuck with 5 but I'd really just want one. They are a 1U model, which I think is the ideal size (short of a laptop or something smaller). You know, for porting to ALPHA_LINUX ALPHA_FREEBSD ALPHA_NETBSD ALPHA_OPENBSD ALPHA_VMS ALPHA_TRU64 ALPHA_NT ?? :) ? I wouldn't make money here, just save myself the space and expense. $200 each plus shipping ($20??). http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&Item=230329596443 Item 230329596443 on eBay. 1gig ram, 30gig drive, 600MHz, single proc no optical drive -- I'd use an external SCSI drive. I'd be willing to [try to] setup any of the first 4 operating systems and send it on. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Mar 17 10:02:44 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 09:02:44 +0000 Subject: [M3devel] socket linger? Message-ID: Can someone please weight on this? I think these two chunks should be identical, though not sure which way they should go. C:\dev2\cm3\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(472): linger := Usocket.struct_linger{1, 1}; C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\SocketWin32.m3(429): linger := WinSock.struct_linger{0, 0}; This is the same as version #1 in the elegosoft history. I haven't checked 3.6. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Mar 17 10:10:11 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 17 Mar 2009 02:10:11 -0700 Subject: [M3devel] socket linger? In-Reply-To: Your message of "Tue, 17 Mar 2009 09:02:44 -0000." Message-ID: <200903170910.n2H9ABm4032328@camembert.async.caltech.edu> Hi Jay, All I can say about this is that one of the things that I have found different about Modula-3 on Unix and Windows is that there are what seems to be some quite serious bugs in the TCP stack on Windows 2000 (and probably earlier versions of NT). They have to do with buffering and buffer sizes. I wouldn't be surprised if fiddling with "linger" is some sort of workaround. (I don't think the linger difference could cause the bug; I think the bug is in the NT kernel.) I don't remember the details but it has something to do with attempting to send or receive a very large amount of data in a single system call on a fast link. Mika Jay writes: >--_ec278f1c-d155-41e4-8856-bb89662f7cd6_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Can someone please weight on this? > >I think these two chunks should be identical=2C though not sure which way t= >hey should go. > >=20 > >=20 > >C:\dev2\cm3\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(472): linger :=3D = >Usocket.struct_linger{1=2C 1}=3B >C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\SocketWin32.m3(429): linger :=3D = >WinSock.struct_linger{0=2C 0}=3B > > >This is the same as version #1 in the elegosoft history. > >I haven't checked 3.6. > >=20 > > - Jay > > > > > > >--_ec278f1c-d155-41e4-8856-bb89662f7cd6_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Can someone please weight on this?
>I think these two chunks should be identical=2C though not sure which way t= >hey should go.
> =3B
> =3B
>C:\dev2\cm3\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(472): =3B =3B= > =3B linger :=3D Usocket.struct_linger{1=2C 1}=3B
C:\dev2\cm3\m3-lib= >s\libm3\src\os\WIN32\SocketWin32.m3(429): =3B =3B =3B linger := >=3D WinSock.struct_linger{0=2C 0}=3B

>This is the same as version #1 in the elegosoft history.
>I haven't checked 3.6.
> =3B
> =3B- Jay





>= > >--_ec278f1c-d155-41e4-8856-bb89662f7cd6_-- From jay.krell at cornell.edu Tue Mar 17 12:51:00 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 11:51:00 +0000 Subject: [M3devel] FW: Usocket.get/setsockopt needs wrappers? In-Reply-To: <20090317112837.DEF3810D6076@birch.elegosoft.com> References: <20090317112837.DEF3810D6076@birch.elegosoft.com> Message-ID: Um...I suggest there should be a type-safe C layer for the various get/setsockopt uses? All this use of ADR and BYTESIZE in the Modula-3 code seems questionable. Yes, I know that Modula-3 is great because it is a systems programming language in which you can do these things. Actually, if the C interface takes void*, it does, then might as well write the type-safe layer in Modula-3. (That is, the C layer wouldn't get any checking.) UsocketOpt.SetLinger(onoff:boolean, timeout:int); UsocketOpt.SetTcpNoDelay(boolean) UsocketOpt.SetSendBufferSize(INTEGER) UsocketOpt.SetRecieveBufferSize(INTEGER); UsocketOpt.SetKeepAlive(BOOLEAN) ? I would implement SetLinger in C, since it uses a struct, but the rest I think all are specified as using int so Modula-3 ok. There is other type-unsafety in Usocket that should probably be wrapped. I don't know, not sure type safety is worth writing all the wrappers, or if everyone gets it right anyway. It looks one of the NoDelay cases is wrong for 64 bit big endian systems. - Jay ---------------------------------------- > Date: Tue, 17 Mar 2009 12:28:37 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/03/17 12:28:37 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Usocket.i3 m3makefile > cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/darwin-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/netbsd-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3 > > Log message: > multi-part experiment > > 1: wrap everything > 2: wrap everything taking input socklen_t > 3: wrap everything taking input/output socklen_t > > Result is removal of platform-specific socklen_t. > But at the cost of 200 lines of C (though really > #1 has nothing to do with socklen_t, #2 is > /perhaps/ optional, #3 is the real part), perhaps > this is not worthwhile. I could argue the 200 > lines are simple and not dense, but "lines are lines"? > Also, this approach is definitely tedious and therefore > error-prone. > > socklen_t so far is 32 bit unsigned everywhere except: > signed on Cygwin > size_t on HP-UX, therefore 64 bits on PA64_HPUX/IA64_HPUX > > There is something fishy going on in that it seems > folks were in places passing ADR(INTEGER) here, which > should fail to compile on everything but Cygwin, esp. > 64 bit platforms. Could be that subranges don't > define different types in this context? > UNTRACED REF BITS 32 FOR [0..1] > same type as UNTRACED REF BITS 32 FOR [0..2]? > > I was considering making changes in the clients instead. > In particular, the in/out socklen_t* is actually only > used for input, but there are a fair number of clients to visit: > m3-comm\tcp\src\POSIX\IP.m3 > m3-comm\tcp\src\POSIX\TCP.m3 > m3-comm\tcp\src\POSIX\TCPExtras.m3 > m3-comm\tcp\src\POSIX\TCPHack.m3 > m3-comm\tcp\src\POSIX\TCPExtras.m3 > m3-comm\tcp\src\POSIX\TCPPeer.m3 > m3-comm\udp\src\POSIX\UDPPosix.m3 > m3-demo\mentor\src\sorting\audio\MidiLineServer.m3 > m3-lectern\lecternclient\src\POSIX\LecternClientPosix.m3 > m3-libs\libm3\src\os\POSIX\SocketPosix.m3 > m3-ui\jvideo\src\POSIX\decunix\JVSink.m3 > m3-ui\jvideo\src\POSIX\decunix\Jv.m3 > From jay.krell at cornell.edu Tue Mar 17 13:50:04 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 12:50:04 +0000 Subject: [M3devel] fcntl int vs. long? Message-ID: ..hm.. C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(77):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(103):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: fcntl int vs. long? > Date: Tue, 17 Mar 2009 12:47:41 +0000 > > > Anyone want to do the research on various systems of the third parameter, for our uses, of fcntl, being int or long? > > Here is it being long on Linux: > > http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/fs/fcntl.c?v=2.6.11.8#L279 > > (unsigned long, but that's not my point -- 32 bits or 64 bits on 64 bit systems). > > The link Daniel sent has it being long on FreeBSD/AMD64. > > - Jay From jay.krell at cornell.edu Tue Mar 17 13:47:41 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 17 Mar 2009 12:47:41 +0000 Subject: [M3devel] fcntl int vs. long? Message-ID: Anyone want to do the research on various systems of the third parameter, for our uses, of fcntl, being int or long? Here is it being long on Linux: http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/fs/fcntl.c?v=2.6.11.8#L279 (unsigned long, but that's not my point -- 32 bits or 64 bits on 64 bit systems). The link Daniel sent has it being long on FreeBSD/AMD64. - Jay From jay.krell at cornell.edu Wed Mar 18 10:11:44 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 18 Mar 2009 09:11:44 +0000 Subject: [M3devel] per thread data? Message-ID: I'm not looking at it right now, but doesn't seem rather piggy to have two thread locals and data on the side? I'm guessing the data on the side is needed because we need to be able to enumerate our threads, to suspend them all? I understand that having multiple thread locals optimizes their use, but it seems greedy. vs. a small heap allocation that combines them. Or in fact.. presumably there could just be one thread local that is the thread pointer, and the handler link could be put at the start, for architectures where zero offset is smaller/faster than non-zero offset. Another idea, of course, is to look into "__thread", "__declspec(thread)". On Windows and probably all platforms they exist on, they are nicely more efficient than pthread_get/setspecific, except on Windows they don't really work acceptably prior to Vista -- they only work in .exes and their static dependencies, not any .dll you load after the process starts with LoadLibrary (dlopen). Does "__thread" work well on most non-Windows platforms? i.e. even if shared object is loaded with dlopen? I could have sworn I saw code out there that was "adaptive". It easily/efficiently checked if it was loaded with LoadLibrary or not. If so, it'd TlsGet/SetValue (pthread_get/setspecific). If not, it'd use __declspec(thread) (__thread). The check was based on if __tlsindex was not zero or somesuch. I couldn't track it down though. In either case, yes, I know, one of the thread locals at least is gone on platforms that have stack walkers, e.g. Solaris, and potentially NT, and maybe others. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Mar 18 15:33:15 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 18 Mar 2009 14:33:15 +0000 Subject: [M3devel] pthreads tls initialization? Message-ID: http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html says that thread locals start as zero, but ThreadPThread.m3 does: PROCEDURE InitHandlers () = BEGIN WITH r = pthread_key_create_handlers() DO END; WITH r = pthread_setspecific_handlers(NIL) DO END; initHandlers := FALSE; END InitHandlers; Any reason for that setspecific call? I ask because I think some of this code should just be written in C. But ideally then, the Win32 code should be too. So I'm just reading them, and they differ oddly in that pthread keeps doing like: if not initialized Initialize() and Win32 allocates its thread up front locals via the Modula initializer. Maybe pthread_key is very expensive, and avoided in single threaded apps? But there aren't any, right, because the runtime creates threads, at least one for the garbage collector? - Jay From hosking at cs.purdue.edu Thu Mar 19 00:14:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Mar 2009 10:14:59 +1100 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: I have no problem putting the exception handler stack thread local into the activation thread local. On 18 Mar 2009, at 20:11, Jay wrote: > I'm not looking at it right now, but doesn't seem rather piggy to > have two thread locals and data on the side? > > > I'm guessing the data on the side is needed because we need to be > able to enumerate our threads, to suspend them all? > > > I understand that having multiple thread locals optimizes their use, > but it seems greedy. > vs. a small heap allocation that combines them. > > Or in fact.. presumably there could just be one thread local that is > the thread pointer, and the handler link could be put at the start, > for architectures where zero offset is smaller/faster than non-zero > offset. > > > Another idea, of course, is to look into "__thread", > "__declspec(thread)". > > On Windows and probably all platforms they exist on, they are nicely > more efficient than pthread_get/setspecific, except on Windows they > don't really work acceptably prior to Vista -- they only work > in .exes and their static dependencies, not any .dll you load after > the process starts with LoadLibrary (dlopen). > > > Does "__thread" work well on most non-Windows platforms? > i.e. even if shared object is loaded with dlopen? > > > I could have sworn I saw code out there that was "adaptive". > It easily/efficiently checked if it was loaded with LoadLibrary or > not. > If so, it'd TlsGet/SetValue (pthread_get/setspecific). > If not, it'd use __declspec(thread) (__thread). > The check was based on if __tlsindex was not zero or somesuch. I > couldn't track it down though. > > > In either case, yes, I know, one of the thread locals at least is > gone on platforms that have stack walkers, e.g. Solaris, and > potentially NT, and maybe others. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 19 00:22:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Mar 2009 10:22:59 +1100 Subject: [M3devel] pthreads tls initialization? In-Reply-To: References: Message-ID: The setspecific call is to initialize the handler stack to nil. It is needed. On 19 Mar 2009, at 01:33, Jay wrote: > > http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html > > > says that thread locals start as zero, but ThreadPThread.m3 does: > > > PROCEDURE InitHandlers () = > BEGIN > WITH r = pthread_key_create_handlers() DO END; > WITH r = pthread_setspecific_handlers(NIL) DO END; > initHandlers := FALSE; > END InitHandlers; > > > Any reason for that setspecific call? > > > I ask because I think some of this code should just be written in C. > But ideally then, the Win32 code should be too. > So I'm just reading them, and they differ oddly in that pthread > keeps doing like: > > > if not initialized Initialize() > > > and Win32 allocates its thread up front locals via the Modula > initializer. > Maybe pthread_key is very expensive, and avoided in single threaded > apps? > But there aren't any, right, because the runtime creates threads, at > least one for the garbage collector? > > > - Jay From jay.krell at cornell.edu Thu Mar 19 02:02:11 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 19 Mar 2009 01:02:11 +0000 Subject: [M3devel] pthreads tls initialization? In-Reply-To: References: Message-ID: But doesn't pthread_create make it so? (More so, it makes it so on any new threads.) Or it that not portable? Or did I misunderstand the opengroup web page? Or other? Or, is this because, like, the Modula-3 notion of "NIL" might not match the pthread notion of "NULL"? I don't believe in that extreme level of portability/disbelief/theory, but... Unless someone can tell me about such a system.. in which void* p = 0; printf("%p\n", p); memset(&p, 0, sizeof(p)); printf("%p\n", q); doesn't print two identical lines. I know the C standard does not guarantee this, and probably therefore Modula-3 doesn't either, but I've never heard of a system on which this isn't true. It seems more theoretical than, say, non-IEEE floating point math (which I believe exists on VAX), or, say, 16 bit integers... - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 19 Mar 2009 10:22:59 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pthreads tls initialization? > > The setspecific call is to initialize the handler stack to nil. It is > needed. > > On 19 Mar 2009, at 01:33, Jay wrote: > > > > > http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html > > > > > > says that thread locals start as zero, but ThreadPThread.m3 does: > > > > > > PROCEDURE InitHandlers () = > > BEGIN > > WITH r = pthread_key_create_handlers() DO END; > > WITH r = pthread_setspecific_handlers(NIL) DO END; > > initHandlers := FALSE; > > END InitHandlers; > > > > > > Any reason for that setspecific call? > > > > > > I ask because I think some of this code should just be written in C. > > But ideally then, the Win32 code should be too. > > So I'm just reading them, and they differ oddly in that pthread > > keeps doing like: > > > > > > if not initialized Initialize() > > > > > > and Win32 allocates its thread up front locals via the Modula > > initializer. > > Maybe pthread_key is very expensive, and avoided in single threaded > > apps? > > But there aren't any, right, because the runtime creates threads, at > > least one for the garbage collector? > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 19 02:03:57 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 19 Mar 2009 01:03:57 +0000 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: Thanks, I should get around to that "soon" then. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Thu, 19 Mar 2009 10:14:59 +1100 CC: m3devel at elegosoft.com Subject: Re: [M3devel] per thread data? I have no problem putting the exception handler stack thread local into the activation thread local. On 18 Mar 2009, at 20:11, Jay wrote: I'm not looking at it right now, but doesn't seem rather piggy to have two thread locals and data on the side? I'm guessing the data on the side is needed because we need to be able to enumerate our threads, to suspend them all? I understand that having multiple thread locals optimizes their use, but it seems greedy. vs. a small heap allocation that combines them. Or in fact.. presumably there could just be one thread local that is the thread pointer, and the handler link could be put at the start, for architectures where zero offset is smaller/faster than non-zero offset. Another idea, of course, is to look into "__thread", "__declspec(thread)". On Windows and probably all platforms they exist on, they are nicely more efficient than pthread_get/setspecific, except on Windows they don't really work acceptably prior to Vista -- they only work in .exes and their static dependencies, not any .dll you load after the process starts with LoadLibrary (dlopen). Does "__thread" work well on most non-Windows platforms? i.e. even if shared object is loaded with dlopen? I could have sworn I saw code out there that was "adaptive". It easily/efficiently checked if it was loaded with LoadLibrary or not. If so, it'd TlsGet/SetValue (pthread_get/setspecific). If not, it'd use __declspec(thread) (__thread). The check was based on if __tlsindex was not zero or somesuch. I couldn't track it down though. In either case, yes, I know, one of the thread locals at least is gone on platforms that have stack walkers, e.g. Solaris, and potentially NT, and maybe others. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 19 02:25:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Mar 2009 12:25:12 +1100 Subject: [M3devel] pthreads tls initialization? In-Reply-To: References: Message-ID: <99081981-8CEC-4392-B2F0-D47A64CA4767@cs.purdue.edu> Sorry, yes, you are correct that the value NULL will also be NIL. So, setspecific NIL is unnecessary. In any case, I do think we should just move the handler stack into Activation and pare things back to just the one threadlocal per thread. On 19 Mar 2009, at 12:02, Jay wrote: > But doesn't pthread_create make it so? (More so, it makes it so on > any new threads.) > Or it that not portable? Or did I misunderstand the opengroup web > page? Or other? > Or, is this because, like, the Modula-3 notion of "NIL" might not > match the pthread notion of "NULL"? I don't believe in that extreme > level of portability/disbelief/theory, but... > Unless someone can tell me about such a system.. in which > void* p = 0; > printf("%p\n", p); > memset(&p, 0, sizeof(p)); > printf("%p\n", q); > > doesn't print two identical lines. > > I know the C standard does not guarantee this, and probably > therefore Modula-3 doesn't either, but I've never heard of a system > on which this isn't true. > It seems more theoretical than, say, non-IEEE floating point math > (which I believe exists on VAX), or, say, 16 bit integers... > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Thu, 19 Mar 2009 10:22:59 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] pthreads tls initialization? > > > > The setspecific call is to initialize the handler stack to nil. It > is > > needed. > > > > On 19 Mar 2009, at 01:33, Jay wrote: > > > > > > > > http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html > > > > > > > > > says that thread locals start as zero, but ThreadPThread.m3 does: > > > > > > > > > PROCEDURE InitHandlers () = > > > BEGIN > > > WITH r = pthread_key_create_handlers() DO END; > > > WITH r = pthread_setspecific_handlers(NIL) DO END; > > > initHandlers := FALSE; > > > END InitHandlers; > > > > > > > > > Any reason for that setspecific call? > > > > > > > > > I ask because I think some of this code should just be written > in C. > > > But ideally then, the Win32 code should be too. > > > So I'm just reading them, and they differ oddly in that pthread > > > keeps doing like: > > > > > > > > > if not initialized Initialize() > > > > > > > > > and Win32 allocates its thread up front locals via the Modula > > > initializer. > > > Maybe pthread_key is very expensive, and avoided in single > threaded > > > apps? > > > But there aren't any, right, because the runtime creates > threads, at > > > least one for the garbage collector? > > > > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 19 08:09:09 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 19 Mar 2009 07:09:09 +0000 Subject: [M3devel] what is "activation" vs. "thread.T" In-Reply-To: <99081981-8CEC-4392-B2F0-D47A64CA4767@cs.purdue.edu> References: <99081981-8CEC-4392-B2F0-D47A64CA4767@cs.purdue.edu> Message-ID: What is meant by an "Activation" vs. a "Thread.T"? Why aren't these just one data structure? Why is there both the global "slots" and the threads are in a circularly linked list? Are there difference between "active" threads, "thread", and "slotted" threads? Or, an active thread is merely one that hasn't finished running yet, is just waiting around for someone to get its result and drop its reference to is, so it can be garbage collected? These things seem closely bound. CreateT takes an activation and sets it in the new T. CreateT always calls AssignSlot. Fork always creates one activation and one T, and always put the activation on the circular linked list. Init only calls CreateT and indirectly creates an activation via InitActivations. Therefore -- I don't see a T ever created without an activation, or vice versa. T contains act. Act does not contain T. Activation is connected back to T via an index into the global slots array. T is garbage collected. Activation is not. Activation is a thread local (pthread/win32). T is not. Is it, like, threads have to be objects, garbage collected, to fit an interface, and.. threads need to be thread local..and thread locals are hidden from the garbage collector normally??? So arbitrarily split them in two? I'm not sure I buy that. If it was true, one of them would be nearly empty, just a way to find the other. The above is mostly all/only about pthread threads. Posix threads have no "activations". Win32 threads also have an idle list. Maybe "activation" is actually small and just the untraced part, mostly, but a little extra crept in? Or, stuff more stuff in it to lighten the load on the garbage collector? Better to put untraced refs within untraced refs, than to put them within traced refs? Or maybe it is a requirement? Or maybe it has to do with locking levels and when traced vs. untraced refs can be touched? That is, the stack is deliberately in the untraced activation so..? - Jay ________________________________ > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 19 Mar 2009 12:25:12 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pthreads tls initialization? > > Sorry, yes, you are correct that the value NULL will also be NIL. So, setspecific NIL is unnecessary. > > In any case, I do think we should just move the handler stack into Activation and pare things back to just the one threadlocal per thread. > > On 19 Mar 2009, at 12:02, Jay wrote: > > But doesn't pthread_create make it so? (More so, it makes it so on any new threads.) > Or it that not portable? Or did I misunderstand the opengroup web page? Or other? > Or, is this because, like, the Modula-3 notion of "NIL" might not match the pthread notion of "NULL"? I don't believe in that extreme level of portability/disbelief/theory, but... > Unless someone can tell me about such a system.. in which > void* p = 0; > printf("%p\n", p); > memset(&p, 0, sizeof(p)); > printf("%p\n", q); > > doesn't print two identical lines. > > I know the C standard does not guarantee this, and probably therefore Modula-3 doesn't either, but I've never heard of a system on which this isn't true. > It seems more theoretical than, say, non-IEEE floating point math (which I believe exists on VAX), or, say, 16 bit integers... > > - Jay > > >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Thu, 19 Mar 2009 10:22:59 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pthreads tls initialization? >> >> The setspecific call is to initialize the handler stack to nil. It is >> needed. >> >> On 19 Mar 2009, at 01:33, Jay wrote: >> >>> >>> http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html >>> >>> >>> says that thread locals start as zero, but ThreadPThread.m3 does: >>> >>> >>> PROCEDURE InitHandlers () = >>> BEGIN >>> WITH r = pthread_key_create_handlers() DO END; >>> WITH r = pthread_setspecific_handlers(NIL) DO END; >>> initHandlers := FALSE; >>> END InitHandlers; >>> >>> >>> Any reason for that setspecific call? >>> >>> >>> I ask because I think some of this code should just be written in C. >>> But ideally then, the Win32 code should be too. >>> So I'm just reading them, and they differ oddly in that pthread >>> keeps doing like: >>> >>> >>> if not initialized Initialize() >>> >>> >>> and Win32 allocates its thread up front locals via the Modula >>> initializer. >>> Maybe pthread_key is very expensive, and avoided in single threaded >>> apps? >>> But there aren't any, right, because the runtime creates threads, at >>> least one for the garbage collector? >>> >>> >>> - Jay >> > From jay.krell at cornell.edu Thu Mar 19 08:47:47 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 19 Mar 2009 07:47:47 +0000 Subject: [M3devel] formsedit crash during startup sometimes? Message-ID: Formsedit on SOLgnu also crashes, sometimes, during startup. It doesn't seem to crash in a debugger, but you can load up the core dump after a crash. It looks very similar as on PPC_DARWIN. In both cases, it is dereferencing the value 4, just after calling RTHooks__CheckLoadTracedRef? Relevant? Coincidence? -bash-3.00$ uname -a SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100 -bash-3.00$ rm core -bash-3.00$ ./formsedit Segmentation Fault (core dumped) -bash-3.00$ dbx ./formsedit ./core ... t at 2 (l at 2) terminated by signal KILL (Killed) 0xfe3c03d0: ___nanosleep+0x0008: bcc,a,pt %icc,___nanosleep+0x18 ! 0xfe3c03e0 (dbx) lwps l at 1 LWP suspended in lwp_yield() >l at 2 LWP suspended in ___nanosleep() l at 3 LWP suspended in __lwp_park() l at 4 LWP suspended in ___nanosleep() l at 11 LWP suspended in __lwp_park() l at 12 LWP suspended in __lwp_park() l at 13 LWP suspended in __lwp_park() o l at 27 signal SIGSEGV in ScrollerVBTClass__PaintViewWithShadows() l at 28 LWP suspended in __lwp_park() (dbx) lwp l at 27 t at 27 (l at 27) stopped in ScrollerVBTClass__PaintViewWithShadows at 0xff1b945c 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld [%g1], %g1 (dbx) dis $pc - 0x10 dbx: warning: unknown language, 'c' assumed 0xff1b941c: ScrollerVBTClass__PaintViewWithShadows+0x0300: inc -4, %g1 0xff1b9420: ScrollerVBTClass__PaintViewWithShadows+0x0304: ld [%g1], %g1 0xff1b9424: ScrollerVBTClass__PaintViewWithShadows+0x0308: sll %g1, 22, %g1 0xff1b9428: ScrollerVBTClass__PaintViewWithShadows+0x030c: srl %g1, 31, %g1 0xff1b942c: ScrollerVBTClass__PaintViewWithShadows+0x0310: btog 1, %g1 0xff1b9430: ScrollerVBTClass__PaintViewWithShadows+0x0314: and %g1, 255, %g1 0xff1b9434: ScrollerVBTClass__PaintViewWithShadows+0x0318: cmp %g1, 0 0xff1b9438: ScrollerVBTClass__PaintViewWithShadows+0x031c: bne,pt %icc,ScrollerVBTClass__Pain tViewWithShadows+0x334 ! 0xff1b9450 0xff1b943c: ScrollerVBTClass__PaintViewWithShadows+0x0320: nop 0xff1b9440: ScrollerVBTClass__PaintViewWithShadows+0x0324: ld [%fp - 24], %g1 (dbx) dis 0xff1b9444: ScrollerVBTClass__PaintViewWithShadows+0x0328: mov %g1, %o0 0xff1b9448: ScrollerVBTClass__PaintViewWithShadows+0x032c: call RTHooks__CheckLoadTracedRef [PLT] ! 0xff2a9518 0xff1b944c: ScrollerVBTClass__PaintViewWithShadows+0x0330: nop 0xff1b9450: ScrollerVBTClass__PaintViewWithShadows+0x0334: ld [%fp + 68], %g3 0xff1b9454: ScrollerVBTClass__PaintViewWithShadows+0x0338: ld [%fp - 24], %g1 0xff1b9458: ScrollerVBTClass__PaintViewWithShadows+0x033c: inc 4, %g1 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld [%g1], %g1 0xff1b9460: ScrollerVBTClass__PaintViewWithShadows+0x0344: st %g1, [%fp - 180] 0xff1b9464: ScrollerVBTClass__PaintViewWithShadows+0x0348: add %fp, -40, %g1 0xff1b9468: ScrollerVBTClass__PaintViewWithShadows+0x034c: add %fp, -180, %g2 (dbx) print $g1 $g1 = 4ULL (dbx) I believe it is on the last line of the function, the PaintTint call (due to what PPC_DARWIN showed). PROCEDURE PaintViewWithShadows (v: T) = VAR dom : Rect.T; stripe: Rect.T; r : Rect.T; f : Rect.Partition; BEGIN dom := VBT.Domain(v); stripe := ComputeStripe(v, dom); (* Paint the scroll. We are careful not to draw the area of the trough that will be covered by the stripe. This helps reduce the flicker. *) r := Rect.Inset(dom, v.shadowPixels); ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Lowered, r, dom); Rect.Factor(r, stripe, f, 0, 0); FOR i := FIRST(f) TO LAST(f) DO IF i # 2 AND NOT Rect.IsEmpty(f[i]) THEN VBT.PaintTint(v, f[i], v.troughColor); END; END; (* Paint the stripe. *) r := Rect.Inset(stripe, v.shadowPixels); ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, r, stripe); VBT.PaintTint(v, r, v.shadow.bg); END PaintViewWithShadows; I'm somewhat just showing people how to get started debugging it, in case folks are as afraid of command line debuggers as I used to be. - Jay From jay.krell at cornell.edu Thu Mar 19 11:22:08 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 19 Mar 2009 10:22:08 +0000 Subject: [M3devel] formsedit crash during startup sometimes? In-Reply-To: References: Message-ID: RTHooks__CheckLoadTracedRef is I'm sure innocent. It gets called before any pointer deref, I guess. The problem is the pointer is sometimes null, sometimes not. And why that is is what we need to figure out. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Thu, 19 Mar 2009 07:47:47 +0000 > Subject: [M3devel] formsedit crash during startup sometimes? > > > Formsedit on SOLgnu also crashes, sometimes, during startup. > It doesn't seem to crash in a debugger, but you can load up the core dump after a crash. It looks very similar as on PPC_DARWIN. > > > In both cases, it is dereferencing the value 4, just after calling RTHooks__CheckLoadTracedRef? Relevant? Coincidence? > > > -bash-3.00$ uname -a > SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100 > -bash-3.00$ rm core > -bash-3.00$ ./formsedit > Segmentation Fault (core dumped) > -bash-3.00$ dbx ./formsedit ./core > ... > t at 2 (l at 2) terminated by signal KILL (Killed) > 0xfe3c03d0: ___nanosleep+0x0008: bcc,a,pt %icc,___nanosleep+0x18 ! 0xfe3c03e0 > (dbx) lwps > l at 1 LWP suspended in lwp_yield() > >l at 2 LWP suspended in ___nanosleep() > l at 3 LWP suspended in __lwp_park() > l at 4 LWP suspended in ___nanosleep() > l at 11 LWP suspended in __lwp_park() > l at 12 LWP suspended in __lwp_park() > l at 13 LWP suspended in __lwp_park() > o l at 27 signal SIGSEGV in ScrollerVBTClass__PaintViewWithShadows() > l at 28 LWP suspended in __lwp_park() > (dbx) lwp l at 27 > t at 27 (l at 27) stopped in ScrollerVBTClass__PaintViewWithShadows at 0xff1b945c > 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld [%g1], %g1 > (dbx) dis $pc - 0x10 > dbx: warning: unknown language, 'c' assumed > 0xff1b941c: ScrollerVBTClass__PaintViewWithShadows+0x0300: inc -4, %g1 > 0xff1b9420: ScrollerVBTClass__PaintViewWithShadows+0x0304: ld [%g1], %g1 > 0xff1b9424: ScrollerVBTClass__PaintViewWithShadows+0x0308: sll %g1, 22, %g1 > 0xff1b9428: ScrollerVBTClass__PaintViewWithShadows+0x030c: srl %g1, 31, %g1 > 0xff1b942c: ScrollerVBTClass__PaintViewWithShadows+0x0310: btog 1, %g1 > 0xff1b9430: ScrollerVBTClass__PaintViewWithShadows+0x0314: and %g1, 255, %g1 > 0xff1b9434: ScrollerVBTClass__PaintViewWithShadows+0x0318: cmp %g1, 0 > 0xff1b9438: ScrollerVBTClass__PaintViewWithShadows+0x031c: bne,pt %icc,ScrollerVBTClass__Pain > tViewWithShadows+0x334 ! 0xff1b9450 > 0xff1b943c: ScrollerVBTClass__PaintViewWithShadows+0x0320: nop > 0xff1b9440: ScrollerVBTClass__PaintViewWithShadows+0x0324: ld [%fp - 24], %g1 > (dbx) dis > 0xff1b9444: ScrollerVBTClass__PaintViewWithShadows+0x0328: mov %g1, %o0 > 0xff1b9448: ScrollerVBTClass__PaintViewWithShadows+0x032c: call RTHooks__CheckLoadTracedRef > [PLT] ! 0xff2a9518 > 0xff1b944c: ScrollerVBTClass__PaintViewWithShadows+0x0330: nop > 0xff1b9450: ScrollerVBTClass__PaintViewWithShadows+0x0334: ld [%fp + 68], %g3 > 0xff1b9454: ScrollerVBTClass__PaintViewWithShadows+0x0338: ld [%fp - 24], %g1 > 0xff1b9458: ScrollerVBTClass__PaintViewWithShadows+0x033c: inc 4, %g1 > 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld [%g1], %g1 > 0xff1b9460: ScrollerVBTClass__PaintViewWithShadows+0x0344: st %g1, [%fp - 180] > 0xff1b9464: ScrollerVBTClass__PaintViewWithShadows+0x0348: add %fp, -40, %g1 > 0xff1b9468: ScrollerVBTClass__PaintViewWithShadows+0x034c: add %fp, -180, %g2 > (dbx) print $g1 > $g1 = 4ULL > (dbx) > > I believe it is on the last line of the function, the PaintTint call (due to what PPC_DARWIN showed). > > > PROCEDURE PaintViewWithShadows (v: T) = > VAR > dom : Rect.T; > stripe: Rect.T; > r : Rect.T; > f : Rect.Partition; > BEGIN > dom := VBT.Domain(v); > stripe := ComputeStripe(v, dom); > (* Paint the scroll. We are careful not to draw the area of the > trough that will be covered by the stripe. This helps reduce > the flicker. *) > r := Rect.Inset(dom, v.shadowPixels); > ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Lowered, > r, dom); > Rect.Factor(r, stripe, f, 0, 0); > FOR i := FIRST(f) TO LAST(f) DO > IF i # 2 AND NOT Rect.IsEmpty(f[i]) THEN > VBT.PaintTint(v, f[i], v.troughColor); > END; > END; > (* Paint the stripe. *) > r := Rect.Inset(stripe, v.shadowPixels); > ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, > r, stripe); > VBT.PaintTint(v, r, v.shadow.bg); > END PaintViewWithShadows; > > > I'm somewhat just showing people how to get started debugging it, in case folks are as afraid of command line debuggers as I used to be. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 19 12:07:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Mar 2009 22:07:56 +1100 Subject: [M3devel] formsedit crash during startup sometimes? In-Reply-To: References: Message-ID: This is a new bug. What changes introduced it? On 19 Mar 2009, at 21:22, Jay wrote: > RTHooks__CheckLoadTracedRef is I'm sure innocent. It gets called > before any pointer deref, I guess. The problem is the pointer is > sometimes null, sometimes not. And why that is is what we need to > figure out. > > - Jay > > > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Thu, 19 Mar 2009 07:47:47 +0000 > > Subject: [M3devel] formsedit crash during startup sometimes? > > > > > > Formsedit on SOLgnu also crashes, sometimes, during startup. > > It doesn't seem to crash in a debugger, but you can load up the > core dump after a crash. It looks very similar as on PPC_DARWIN. > > > > > > In both cases, it is dereferencing the value 4, just after calling > RTHooks__CheckLoadTracedRef? Relevant? Coincidence? > > > > > > -bash-3.00$ uname -a > > SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100 > > -bash-3.00$ rm core > > -bash-3.00$ ./formsedit > > Segmentation Fault (core dumped) > > -bash-3.00$ dbx ./formsedit ./core > > ... > > t at 2 (l at 2) terminated by signal KILL (Killed) > > 0xfe3c03d0: ___nanosleep+0x0008: bcc,a,pt %icc,___nanosleep+0x18 ! > 0xfe3c03e0 > > (dbx) lwps > > l at 1 LWP suspended in lwp_yield() > > >l at 2 LWP suspended in ___nanosleep() > > l at 3 LWP suspended in __lwp_park() > > l at 4 LWP suspended in ___nanosleep() > > l at 11 LWP suspended in __lwp_park() > > l at 12 LWP suspended in __lwp_park() > > l at 13 LWP suspended in __lwp_park() > > o l at 27 signal SIGSEGV in ScrollerVBTClass__PaintViewWithShadows() > > l at 28 LWP suspended in __lwp_park() > > (dbx) lwp l at 27 > > t at 27 (l at 27) stopped in ScrollerVBTClass__PaintViewWithShadows at > 0xff1b945c > > 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld > [%g1], %g1 > > (dbx) dis $pc - 0x10 > > dbx: warning: unknown language, 'c' assumed > > 0xff1b941c: ScrollerVBTClass__PaintViewWithShadows+0x0300: inc -4, > %g1 > > 0xff1b9420: ScrollerVBTClass__PaintViewWithShadows+0x0304: ld > [%g1], %g1 > > 0xff1b9424: ScrollerVBTClass__PaintViewWithShadows+0x0308: sll > %g1, 22, %g1 > > 0xff1b9428: ScrollerVBTClass__PaintViewWithShadows+0x030c: srl > %g1, 31, %g1 > > 0xff1b942c: ScrollerVBTClass__PaintViewWithShadows+0x0310: btog 1, > %g1 > > 0xff1b9430: ScrollerVBTClass__PaintViewWithShadows+0x0314: and > %g1, 255, %g1 > > 0xff1b9434: ScrollerVBTClass__PaintViewWithShadows+0x0318: cmp > %g1, 0 > > 0xff1b9438: ScrollerVBTClass__PaintViewWithShadows+0x031c: bne,pt > %icc,ScrollerVBTClass__Pain > > tViewWithShadows+0x334 ! 0xff1b9450 > > 0xff1b943c: ScrollerVBTClass__PaintViewWithShadows+0x0320: nop > > 0xff1b9440: ScrollerVBTClass__PaintViewWithShadows+0x0324: ld [%fp > - 24], %g1 > > (dbx) dis > > 0xff1b9444: ScrollerVBTClass__PaintViewWithShadows+0x0328: mov > %g1, %o0 > > 0xff1b9448: ScrollerVBTClass__PaintViewWithShadows+0x032c: call > RTHooks__CheckLoadTracedRef > > [PLT] ! 0xff2a9518 > > 0xff1b944c: ScrollerVBTClass__PaintViewWithShadows+0x0330: nop > > 0xff1b9450: ScrollerVBTClass__PaintViewWithShadows+0x0334: ld [%fp > + 68], %g3 > > 0xff1b9454: ScrollerVBTClass__PaintViewWithShadows+0x0338: ld [%fp > - 24], %g1 > > 0xff1b9458: ScrollerVBTClass__PaintViewWithShadows+0x033c: inc 4, > %g1 > > 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld > [%g1], %g1 > > 0xff1b9460: ScrollerVBTClass__PaintViewWithShadows+0x0344: st %g1, > [%fp - 180] > > 0xff1b9464: ScrollerVBTClass__PaintViewWithShadows+0x0348: add > %fp, -40, %g1 > > 0xff1b9468: ScrollerVBTClass__PaintViewWithShadows+0x034c: add > %fp, -180, %g2 > > (dbx) print $g1 > > $g1 = 4ULL > > (dbx) > > > > I believe it is on the last line of the function, the PaintTint > call (due to what PPC_DARWIN showed). > > > > > > PROCEDURE PaintViewWithShadows (v: T) = > > VAR > > dom : Rect.T; > > stripe: Rect.T; > > r : Rect.T; > > f : Rect.Partition; > > BEGIN > > dom := VBT.Domain(v); > > stripe := ComputeStripe(v, dom); > > (* Paint the scroll. We are careful not to draw the area of the > > trough that will be covered by the stripe. This helps reduce > > the flicker. *) > > r := Rect.Inset(dom, v.shadowPixels); > > ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Lowered, > > r, dom); > > Rect.Factor(r, stripe, f, 0, 0); > > FOR i := FIRST(f) TO LAST(f) DO > > IF i # 2 AND NOT Rect.IsEmpty(f[i]) THEN > > VBT.PaintTint(v, f[i], v.troughColor); > > END; > > END; > > (* Paint the stripe. *) > > r := Rect.Inset(stripe, v.shadowPixels); > > ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, > > r, stripe); > > VBT.PaintTint(v, r, v.shadow.bg); > > END PaintViewWithShadows; > > > > > > I'm somewhat just showing people how to get started debugging it, > in case folks are as afraid of command line debuggers as I used to be. > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Thu Mar 19 13:27:11 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 19 Mar 2009 07:27:11 -0500 Subject: [M3devel] [Fwd: Prentice-Hall says no] Message-ID: <49C23A1F.1070800@bellsouth.net> An embedded message was scrubbed... From: Greg Nelson Subject: Prentice-Hall says no Date: Wed, 18 Mar 2009 21:17:19 -0700 Size: 4747 URL: From hosking at cs.purdue.edu Thu Mar 19 12:05:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Mar 2009 22:05:02 +1100 Subject: [M3devel] what is "activation" vs. "thread.T" In-Reply-To: References: <99081981-8CEC-4392-B2F0-D47A64CA4767@cs.purdue.edu> Message-ID: On 19 Mar 2009, at 18:09, Jay wrote: > > What is meant by an "Activation" UNTRACED > vs. a "Thread.T"? TRACED I don't recall the specifics, but it was needed at some point. Here be dragons. I'll try to reconstruct the reasoning... > Why aren't these just one data structure? > > > Why is there both the global "slots" and the threads are in a > circularly linked list? > > Are there difference between "active" threads, "thread", and > "slotted" threads? > Or, an active thread is merely one that hasn't finished running yet, > is just waiting around for someone to get its result and drop its > reference to is, so it can be garbage collected? > > These things seem closely bound. > CreateT takes an activation and sets it in the new T. > CreateT always calls AssignSlot. > > Fork always creates one activation and one T, and always put the > activation on the circular linked list. > > Init only calls CreateT and indirectly creates an activation via > InitActivations. > > Therefore -- I don't see a T ever created without an activation, or > vice versa. > > T contains act. > Act does not contain T. > Activation is connected back to T via an index into the global slots > array. > > T is garbage collected. > Activation is not. > Activation is a thread local (pthread/win32). > T is not. > > Is it, like, threads have to be objects, garbage collected, to fit > an interface, and.. threads need to be thread local..and thread > locals are hidden from the garbage collector normally??? So > arbitrarily split them in two? > I'm not sure I buy that. If it was true, one of them would be nearly > empty, just a way to find the other. > > > The above is mostly all/only about pthread threads. > Posix threads have no "activations". > Win32 threads also have an idle list. > > Maybe "activation" is actually small and just the untraced part, > mostly, but a little extra crept in? Or, stuff more stuff in it to > lighten the load on the garbage collector? Better to put untraced > refs within untraced refs, than to put them within traced refs? Or > maybe it is a requirement? > > Or maybe it has to do with locking levels and when traced vs. > untraced refs can be touched? That is, the stack is deliberately in > the untraced activation so..? > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Thu, 19 Mar 2009 12:25:12 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pthreads tls initialization? >> >> Sorry, yes, you are correct that the value NULL will also be NIL. >> So, setspecific NIL is unnecessary. >> >> In any case, I do think we should just move the handler stack into >> Activation and pare things back to just the one threadlocal per >> thread. >> >> On 19 Mar 2009, at 12:02, Jay wrote: >> >> But doesn't pthread_create make it so? (More so, it makes it so on >> any new threads.) >> Or it that not portable? Or did I misunderstand the opengroup web >> page? Or other? >> Or, is this because, like, the Modula-3 notion of "NIL" might not >> match the pthread notion of "NULL"? I don't believe in that extreme >> level of portability/disbelief/theory, but... >> Unless someone can tell me about such a system.. in which >> void* p = 0; >> printf("%p\n", p); >> memset(&p, 0, sizeof(p)); >> printf("%p\n", q); >> >> doesn't print two identical lines. >> >> I know the C standard does not guarantee this, and probably >> therefore Modula-3 doesn't either, but I've never heard of a system >> on which this isn't true. >> It seems more theoretical than, say, non-IEEE floating point math >> (which I believe exists on VAX), or, say, 16 bit integers... >> >> - Jay >> >> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Thu, 19 Mar 2009 10:22:59 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] pthreads tls initialization? >>> >>> The setspecific call is to initialize the handler stack to nil. It >>> is >>> needed. >>> >>> On 19 Mar 2009, at 01:33, Jay wrote: >>> >>>> >>>> http://www.opengroup.org/onlinepubs/000095399/functions/pthread_key_create.html >>>> >>>> >>>> says that thread locals start as zero, but ThreadPThread.m3 does: >>>> >>>> >>>> PROCEDURE InitHandlers () = >>>> BEGIN >>>> WITH r = pthread_key_create_handlers() DO END; >>>> WITH r = pthread_setspecific_handlers(NIL) DO END; >>>> initHandlers := FALSE; >>>> END InitHandlers; >>>> >>>> >>>> Any reason for that setspecific call? >>>> >>>> >>>> I ask because I think some of this code should just be written in >>>> C. >>>> But ideally then, the Win32 code should be too. >>>> So I'm just reading them, and they differ oddly in that pthread >>>> keeps doing like: >>>> >>>> >>>> if not initialized Initialize() >>>> >>>> >>>> and Win32 allocates its thread up front locals via the Modula >>>> initializer. >>>> Maybe pthread_key is very expensive, and avoided in single threaded >>>> apps? >>>> But there aren't any, right, because the runtime creates threads, >>>> at >>>> least one for the garbage collector? >>>> >>>> >>>> - Jay >>> >> From jay.krell at cornell.edu Fri Mar 20 00:18:17 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 19 Mar 2009 23:18:17 +0000 Subject: [M3devel] formsedit crash during startup sometimes? In-Reply-To: References: Message-ID: I don't know yet. I just know that it happens before and after switching to "new small unix/*.i3 files", so not that. I'm away for a few days with only an x86 laptop, I might get around to testing something in a virtual machine, see if repros. Otherwise it'll wait a bit. Soon I will probably resort to going back to 5.4.0 or something, verifying no repro, then do "time bisection" or whatever you call it ("binary search"?) -- jump ahead some chunk of time, ideally half way between then and now, see if it repros, jump forward or backward half again depending on if it repros, etc.. Wouldn't it be super cool, though if I could just issue one command, wait overnight or whatever, and voila, several of those builds done, in both directions, just awaiting human test/observation? Yeah.. I don't even know how yet to sync an entire CVS tree to a date yet, maybe cvs upd -d? (Nice thing about 5.4.0 is I don't need CVS to identify it.) I also need to ensure that the non-repro case hits the line in question and if so..well, what I'd really love to do, but not sure how viable it is, is write code within the running system (before it runs), to set a hardware breakpoint on the appropriate address, for each appropriate address as the data types are created, and just have dump core when it hits. I wasn't able to get it to even repro in debugger for SOLgnu. I'll try PPC_DARWIN in a debugger, but even if it repros I'm a bit pessimistic on tracking it down. Bisection while tedious and slow should definitely converge on the answer. - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] formsedit crash during startup sometimes? > Date: Thu, 19 Mar 2009 22:07:56 +1100 > > This is a new bug. What changes introduced it? > > On 19 Mar 2009, at 21:22, Jay wrote: > > RTHooks__CheckLoadTracedRef is I'm sure innocent. It gets called before any pointer deref, I guess. The problem is the pointer is sometimes null, sometimes not. And why that is is what we need to figure out. > > - Jay > > >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Thu, 19 Mar 2009 07:47:47 +0000 >> Subject: [M3devel] formsedit crash during startup sometimes? >> >> >> Formsedit on SOLgnu also crashes, sometimes, during startup. >> It doesn't seem to crash in a debugger, but you can load up the core dump after a crash. It looks very similar as on PPC_DARWIN. >> >> >> In both cases, it is dereferencing the value 4, just after calling RTHooks__CheckLoadTracedRef? Relevant? Coincidence? >> >> >> -bash-3.00$ uname -a >> SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100 >> -bash-3.00$ rm core >> -bash-3.00$ ./formsedit >> Segmentation Fault (core dumped) >> -bash-3.00$ dbx ./formsedit ./core >> ... >> t at 2 (l at 2) terminated by signal KILL (Killed) >> 0xfe3c03d0: ___nanosleep+0x0008: bcc,a,pt %icc,___nanosleep+0x18 ! 0xfe3c03e0 >> (dbx) lwps >> l at 1 LWP suspended in lwp_yield() >>>l at 2 LWP suspended in ___nanosleep() >> l at 3 LWP suspended in __lwp_park() >> l at 4 LWP suspended in ___nanosleep() >> l at 11 LWP suspended in __lwp_park() >> l at 12 LWP suspended in __lwp_park() >> l at 13 LWP suspended in __lwp_park() >> o l at 27 signal SIGSEGV in ScrollerVBTClass__PaintViewWithShadows() >> l at 28 LWP suspended in __lwp_park() >> (dbx) lwp l at 27 >> t at 27 (l at 27) stopped in ScrollerVBTClass__PaintViewWithShadows at 0xff1b945c >> 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld [%g1], %g1 >> (dbx) dis $pc - 0x10 >> dbx: warning: unknown language, 'c' assumed >> 0xff1b941c: ScrollerVBTClass__PaintViewWithShadows+0x0300: inc -4, %g1 >> 0xff1b9420: ScrollerVBTClass__PaintViewWithShadows+0x0304: ld [%g1], %g1 >> 0xff1b9424: ScrollerVBTClass__PaintViewWithShadows+0x0308: sll %g1, 22, %g1 >> 0xff1b9428: ScrollerVBTClass__PaintViewWithShadows+0x030c: srl %g1, 31, %g1 >> 0xff1b942c: ScrollerVBTClass__PaintViewWithShadows+0x0310: btog 1, %g1 >> 0xff1b9430: ScrollerVBTClass__PaintViewWithShadows+0x0314: and %g1, 255, %g1 >> 0xff1b9434: ScrollerVBTClass__PaintViewWithShadows+0x0318: cmp %g1, 0 >> 0xff1b9438: ScrollerVBTClass__PaintViewWithShadows+0x031c: bne,pt %icc,ScrollerVBTClass__Pain >> tViewWithShadows+0x334 ! 0xff1b9450 >> 0xff1b943c: ScrollerVBTClass__PaintViewWithShadows+0x0320: nop >> 0xff1b9440: ScrollerVBTClass__PaintViewWithShadows+0x0324: ld [%fp - 24], %g1 >> (dbx) dis >> 0xff1b9444: ScrollerVBTClass__PaintViewWithShadows+0x0328: mov %g1, %o0 >> 0xff1b9448: ScrollerVBTClass__PaintViewWithShadows+0x032c: call RTHooks__CheckLoadTracedRef >> [PLT] ! 0xff2a9518 >> 0xff1b944c: ScrollerVBTClass__PaintViewWithShadows+0x0330: nop >> 0xff1b9450: ScrollerVBTClass__PaintViewWithShadows+0x0334: ld [%fp + 68], %g3 >> 0xff1b9454: ScrollerVBTClass__PaintViewWithShadows+0x0338: ld [%fp - 24], %g1 >> 0xff1b9458: ScrollerVBTClass__PaintViewWithShadows+0x033c: inc 4, %g1 >> 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld [%g1], %g1 >> 0xff1b9460: ScrollerVBTClass__PaintViewWithShadows+0x0344: st %g1, [%fp - 180] >> 0xff1b9464: ScrollerVBTClass__PaintViewWithShadows+0x0348: add %fp, -40, %g1 >> 0xff1b9468: ScrollerVBTClass__PaintViewWithShadows+0x034c: add %fp, -180, %g2 >> (dbx) print $g1 >> $g1 = 4ULL >> (dbx) >> >> I believe it is on the last line of the function, the PaintTint call (due to what PPC_DARWIN showed). >> >> >> PROCEDURE PaintViewWithShadows (v: T) = >> VAR >> dom : Rect.T; >> stripe: Rect.T; >> r : Rect.T; >> f : Rect.Partition; >> BEGIN >> dom := VBT.Domain(v); >> stripe := ComputeStripe(v, dom); >> (* Paint the scroll. We are careful not to draw the area of the >> trough that will be covered by the stripe. This helps reduce >> the flicker. *) >> r := Rect.Inset(dom, v.shadowPixels); >> ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Lowered, >> r, dom); >> Rect.Factor(r, stripe, f, 0, 0); >> FOR i := FIRST(f) TO LAST(f) DO >> IF i # 2 AND NOT Rect.IsEmpty(f[i]) THEN >> VBT.PaintTint(v, f[i], v.troughColor); >> END; >> END; >> (* Paint the stripe. *) >> r := Rect.Inset(stripe, v.shadowPixels); >> ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, >> r, stripe); >> VBT.PaintTint(v, r, v.shadow.bg); >> END PaintViewWithShadows; >> >> >> I'm somewhat just showing people how to get started debugging it, in case folks are as afraid of command line debuggers as I used to be. >> >> >> - Jay > From hosking at cs.purdue.edu Fri Mar 20 00:39:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 20 Mar 2009 10:39:44 +1100 Subject: [M3devel] formsedit crash during startup sometimes? In-Reply-To: References: Message-ID: I may have some time to look at this later next week. On 20 Mar 2009, at 10:18, Jay wrote: > > I don't know yet. > I just know that it happens before and after switching to "new small > unix/*.i3 files", so not that. > > > I'm away for a few days with only an x86 laptop, I might get around > to testing something in a virtual machine, see if repros. Otherwise > it'll wait a bit. > > > Soon I will probably resort to going back to 5.4.0 or something, > verifying no repro, then do "time bisection" or whatever you call it > ("binary search"?) -- jump ahead some chunk of time, ideally half > way between then and now, see if it repros, jump forward or backward > half again depending on if it repros, etc.. > > > Wouldn't it be super cool, though if I could just issue one command, > wait overnight or whatever, and voila, several of those builds done, > in both directions, just awaiting human test/observation? Yeah.. > > > I don't even know how yet to sync an entire CVS tree to a date yet, > maybe cvs upd -d? > (Nice thing about 5.4.0 is I don't need CVS to identify it.) > > > I also need to ensure that the non-repro case hits the line in > question and if so..well, what I'd really love to do, but not sure > how viable it is, is write code within the running system (before it > runs), to set a hardware breakpoint on the appropriate address, for > each appropriate address as the data types are created, and just > have dump core when it hits. I wasn't able to get it to even repro > in debugger for SOLgnu. I'll try PPC_DARWIN in a debugger, but even > if it repros I'm a bit pessimistic on tracking it down. > > Bisection while tedious and slow should definitely converge on the > answer. > > > - Jay > > > ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] formsedit crash during startup sometimes? >> Date: Thu, 19 Mar 2009 22:07:56 +1100 >> >> This is a new bug. What changes introduced it? >> >> On 19 Mar 2009, at 21:22, Jay wrote: >> >> RTHooks__CheckLoadTracedRef is I'm sure innocent. It gets called >> before any pointer deref, I guess. The problem is the pointer is >> sometimes null, sometimes not. And why that is is what we need to >> figure out. >> >> - Jay >> >> >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Thu, 19 Mar 2009 07:47:47 +0000 >>> Subject: [M3devel] formsedit crash during startup sometimes? >>> >>> >>> Formsedit on SOLgnu also crashes, sometimes, during startup. >>> It doesn't seem to crash in a debugger, but you can load up the >>> core dump after a crash. It looks very similar as on PPC_DARWIN. >>> >>> >>> In both cases, it is dereferencing the value 4, just after calling >>> RTHooks__CheckLoadTracedRef? Relevant? Coincidence? >>> >>> >>> -bash-3.00$ uname -a >>> SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100 >>> -bash-3.00$ rm core >>> -bash-3.00$ ./formsedit >>> Segmentation Fault (core dumped) >>> -bash-3.00$ dbx ./formsedit ./core >>> ... >>> t at 2 (l at 2) terminated by signal KILL (Killed) >>> 0xfe3c03d0: ___nanosleep+0x0008: bcc,a,pt %icc,___nanosleep+0x18 ! >>> 0xfe3c03e0 >>> (dbx) lwps >>> l at 1 LWP suspended in lwp_yield() >>>> l at 2 LWP suspended in ___nanosleep() >>> l at 3 LWP suspended in __lwp_park() >>> l at 4 LWP suspended in ___nanosleep() >>> l at 11 LWP suspended in __lwp_park() >>> l at 12 LWP suspended in __lwp_park() >>> l at 13 LWP suspended in __lwp_park() >>> o l at 27 signal SIGSEGV in ScrollerVBTClass__PaintViewWithShadows() >>> l at 28 LWP suspended in __lwp_park() >>> (dbx) lwp l at 27 >>> t at 27 (l at 27) stopped in ScrollerVBTClass__PaintViewWithShadows at >>> 0xff1b945c >>> 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld >>> [%g1], %g1 >>> (dbx) dis $pc - 0x10 >>> dbx: warning: unknown language, 'c' assumed >>> 0xff1b941c: ScrollerVBTClass__PaintViewWithShadows+0x0300: inc -4, >>> %g1 >>> 0xff1b9420: ScrollerVBTClass__PaintViewWithShadows+0x0304: ld >>> [%g1], %g1 >>> 0xff1b9424: ScrollerVBTClass__PaintViewWithShadows+0x0308: sll >>> %g1, 22, %g1 >>> 0xff1b9428: ScrollerVBTClass__PaintViewWithShadows+0x030c: srl >>> %g1, 31, %g1 >>> 0xff1b942c: ScrollerVBTClass__PaintViewWithShadows+0x0310: btog 1, >>> %g1 >>> 0xff1b9430: ScrollerVBTClass__PaintViewWithShadows+0x0314: and >>> %g1, 255, %g1 >>> 0xff1b9434: ScrollerVBTClass__PaintViewWithShadows+0x0318: cmp >>> %g1, 0 >>> 0xff1b9438: ScrollerVBTClass__PaintViewWithShadows+0x031c: bne,pt >>> %icc,ScrollerVBTClass__Pain >>> tViewWithShadows+0x334 ! 0xff1b9450 >>> 0xff1b943c: ScrollerVBTClass__PaintViewWithShadows+0x0320: nop >>> 0xff1b9440: ScrollerVBTClass__PaintViewWithShadows+0x0324: ld [%fp >>> - 24], %g1 >>> (dbx) dis >>> 0xff1b9444: ScrollerVBTClass__PaintViewWithShadows+0x0328: mov >>> %g1, %o0 >>> 0xff1b9448: ScrollerVBTClass__PaintViewWithShadows+0x032c: call >>> RTHooks__CheckLoadTracedRef >>> [PLT] ! 0xff2a9518 >>> 0xff1b944c: ScrollerVBTClass__PaintViewWithShadows+0x0330: nop >>> 0xff1b9450: ScrollerVBTClass__PaintViewWithShadows+0x0334: ld [%fp >>> + 68], %g3 >>> 0xff1b9454: ScrollerVBTClass__PaintViewWithShadows+0x0338: ld [%fp >>> - 24], %g1 >>> 0xff1b9458: ScrollerVBTClass__PaintViewWithShadows+0x033c: inc 4, >>> %g1 >>> 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld >>> [%g1], %g1 >>> 0xff1b9460: ScrollerVBTClass__PaintViewWithShadows+0x0344: st %g1, >>> [%fp - 180] >>> 0xff1b9464: ScrollerVBTClass__PaintViewWithShadows+0x0348: add >>> %fp, -40, %g1 >>> 0xff1b9468: ScrollerVBTClass__PaintViewWithShadows+0x034c: add >>> %fp, -180, %g2 >>> (dbx) print $g1 >>> $g1 = 4ULL >>> (dbx) >>> >>> I believe it is on the last line of the function, the PaintTint >>> call (due to what PPC_DARWIN showed). >>> >>> >>> PROCEDURE PaintViewWithShadows (v: T) = >>> VAR >>> dom : Rect.T; >>> stripe: Rect.T; >>> r : Rect.T; >>> f : Rect.Partition; >>> BEGIN >>> dom := VBT.Domain(v); >>> stripe := ComputeStripe(v, dom); >>> (* Paint the scroll. We are careful not to draw the area of the >>> trough that will be covered by the stripe. This helps reduce >>> the flicker. *) >>> r := Rect.Inset(dom, v.shadowPixels); >>> ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Lowered, >>> r, dom); >>> Rect.Factor(r, stripe, f, 0, 0); >>> FOR i := FIRST(f) TO LAST(f) DO >>> IF i # 2 AND NOT Rect.IsEmpty(f[i]) THEN >>> VBT.PaintTint(v, f[i], v.troughColor); >>> END; >>> END; >>> (* Paint the stripe. *) >>> r := Rect.Inset(stripe, v.shadowPixels); >>> ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised, >>> r, stripe); >>> VBT.PaintTint(v, r, v.shadow.bg); >>> END PaintViewWithShadows; >>> >>> >>> I'm somewhat just showing people how to get started debugging it, >>> in case folks are as afraid of command line debuggers as I used to >>> be. >>> >>> >>> - Jay >> From wagner at elegosoft.com Fri Mar 20 08:09:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Mar 2009 08:09:26 +0100 Subject: [M3devel] formsedit crash during startup sometimes? In-Reply-To: References: Message-ID: <20090320080926.7b6ishzqs8w4k4g4@mail.elegosoft.com> Quoting Jay : > Wouldn't it be super cool, though if I could just issue one command, > wait overnight or whatever, and voila, several of those builds > done, in both directions, just awaiting human test/observation? > Yeah.. > > I don't even know how yet to sync an entire CVS tree to a date yet, > maybe cvs upd -d? > (Nice thing about 5.4.0 is I don't need CVS to identify it.) It's the capital D and easily available in online help: % cvs co -h co: invalid option -- h Usage: cvs checkout [-ANPRcflnps] [-r rev] [-D date] [-d dir] [-j rev1] [-j rev2] [-k kopt] modules... -A Reset any sticky tags/date/kopts. -N Don't shorten module paths if -d specified. -P Prune empty directories. -R Process directories recursively. -c "cat" the module database. -f Force a head revision match if tag/date not found. -l Local directory only, not recursive -n Do not run module program (if any). -p Check out files to standard output (avoids stickiness). -s Like -c, but include module status. -r rev Check out revision or tag. (implies -P) (is sticky) -D date Check out revisions as of date. (implies -P) (is sticky) -d dir Check out into dir instead of module name. -k kopt Use RCS kopt -k option on checkout. (is sticky) -j rev Merge in changes made between current revision and rev. (Specify the --help global option for a list of other help options) luthien [~] wagner % cvs update -h update: invalid option -- h Usage: cvs update [-APCdflRp] [-k kopt] [-r rev] [-D date] [-j rev] [-I ign] [-W spec] [files...] -A Reset any sticky tags/date/kopts. -P Prune empty directories. -C Overwrite locally modified files with clean repository copies. -d Build directories, like checkout does. -f Force a head revision match if tag/date not found. -l Local directory only, no recursion. -R Process directories recursively. -p Send updates to standard output (avoids stickiness). -k kopt Use RCS kopt -k option on checkout. (is sticky) -r rev Update using specified revision/tag (is sticky). -D date Set date to update from (is sticky). -j rev Merge in changes made between current revision and rev. -I ign More files to ignore (! to reset). -W spec Wrappers specification line. (Specify the --help global option for a list of other help options) Usually it's better to use tags instead of dates, since the latter need not identify a consistent configuration, but for your purpose it should be OK. Information about CVS is available from a number of online sources. freebsd.org offers a nice possibility to read manual pages online for example: http://www.freebsd.org/cgi/man.cgi?query=cvs&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE&format=html Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Fri Mar 20 14:14:36 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 20 Mar 2009 09:14:36 -0400 Subject: [M3devel] trestle protability Message-ID: <20090320131436.GA4463@topoi.pooq.com> I'm planning an application (kind of a a pixel editor with variable-sized pixels) that has to do mouse tracking. Now that's available in Trestle, so (in principle) no problem there. But this program, ideally, should run on both Linux and Windows. So I ask: do the Windows version(s) of modula3 have sufficiently compatible implementations of Trestle? I have limited resources for debugging Windows code; ideally no source-code change would be required. If not, are there other UI libraries available fo Midula 3 that *are* compatible? -- hendrik From mika at async.caltech.edu Fri Mar 20 15:34:56 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Mar 2009 07:34:56 -0700 Subject: [M3devel] trestle protability In-Reply-To: Your message of "Fri, 20 Mar 2009 09:14:36 EDT." <20090320131436.GA4463@topoi.pooq.com> Message-ID: <200903201434.n2KEYuBg036310@camembert.async.caltech.edu> It should work. I get a window popping up and then a crash in ThreadWin32.m3 when I try to run mentor on a win2k machine, but I'm using PM3/Klagenfurt... surely the new code works better :-) hendrik at topoi.pooq.com writes: >I'm planning an application (kind of a a pixel editor with >variable-sized pixels) that has to do mouse tracking. Now that's >available in Trestle, so (in principle) no problem there. But this >program, ideally, should run on both Linux and Windows. So I ask: do >the Windows version(s) of modula3 have sufficiently compatible >implementations of Trestle? I have limited resources for debugging >Windows code; ideally no source-code change would be required. > >If not, are there other UI libraries available fo Midula 3 that *are* >compatible? > >-- hendrik From mika at async.caltech.edu Fri Mar 20 15:36:03 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Mar 2009 07:36:03 -0700 Subject: [M3devel] trestle protability In-Reply-To: Your message of "Fri, 20 Mar 2009 09:14:36 EDT." <20090320131436.GA4463@topoi.pooq.com> Message-ID: <200903201436.n2KEa3J3036438@camembert.async.caltech.edu> And mentor works great on a win 2003 server system.... even with PM3/Klagenfurt. So you should be OK... hendrik at topoi.pooq.com writes: >I'm planning an application (kind of a a pixel editor with >variable-sized pixels) that has to do mouse tracking. Now that's >available in Trestle, so (in principle) no problem there. But this >program, ideally, should run on both Linux and Windows. So I ask: do >the Windows version(s) of modula3 have sufficiently compatible >implementations of Trestle? I have limited resources for debugging >Windows code; ideally no source-code change would be required. > >If not, are there other UI libraries available fo Midula 3 that *are* >compatible? > >-- hendrik From rcoleburn at scires.com Fri Mar 20 18:50:01 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 20 Mar 2009 13:50:01 -0400 Subject: [M3devel] trestle protability In-Reply-To: <20090320131436.GA4463@topoi.pooq.com> References: <20090320131436.GA4463@topoi.pooq.com> Message-ID: <49C39E6D.1E75.00D7.1@scires.com> Hendrik: I've been using Trestle and FormsVBT on Windows for years. I've got such programs that run on both HPUX and Windows. Regards, Randy >>> 3/20/2009 9:14 AM >>> I'm planning an application (kind of a a pixel editor with variable-sized pixels) that has to do mouse tracking. Now that's available in Trestle, so (in principle) no problem there. But this program, ideally, should run on both Linux and Windows. So I ask: do the Windows version(s) of modula3 have sufficiently compatible implementations of Trestle? I have limited resources for debugging Windows code; ideally no source-code change would be required. If not, are there other UI libraries available fo Midula 3 that *are* compatible? -- hendrik CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Mar 23 18:37:34 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Mar 2009 10:37:34 -0700 (PDT) Subject: [M3devel] About 404 http https error at opencm3.net elegosoft.com modula3.org Message-ID: <577748.77637.qm@web24706.mail.ird.yahoo.com> Hi all: just want to make sure I can't access? the web pages of the server. Is it working well ? on https://elegosoft.com/ or http://elegosoft.com/ I got 404 error from the common urls Not Found The requested URL / was not found on this server. Apache Server at www.opencm3.net Port 80 However server does respond to ICMP requests and I guess other services (including http) ping opencm3.net PING opencm3.net (88.198.39.217) 56(84) bytes of data. 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=1 ttl=54 time=117 ms 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=2 ttl=54 time=115 ms 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=3 ttl=54 time=115 ms 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=4 ttl=54 time=115 ms 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=5 ttl=54 time=115 ms 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=6 ttl=54 time=115 ms --- opencm3.net ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 4998ms rtt min/avg/max/mdev = 115.483/115.854/117.030/0.578 ms And I can't get any web page on http or https wget opencm3.net --12:08:02--? http://opencm3.net/ ?????????? => `index.html' Resolving opencm3.net... 88.198.39.217 Connecting to opencm3.net|88.198.39.217|:80... connected. HTTP request sent, awaiting response... 404 Not Found 12:08:02 ERROR 404: Not Found. wget https://opencm3.net --no-check-certificate --12:13:25--? https://opencm3.net/ ?????????? => `index.html' Resolving opencm3.net... 88.198.39.217 Connecting to opencm3.net|88.198.39.217|:443... connected. WARNING: Certificate verification error for opencm3.net: self signed certificate in certificate chain WARNING: certificate common name `wiki.elegosoft.com' doesn't match requested host name `opencm3.net'. HTTP request sent, awaiting response... 404 Not Found 12:13:25 ERROR 404: Not Found. I can't rememeber now my elego.de user passsword so I can't diagnose further more. Can any one check further on the web server? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Mon Mar 23 20:32:41 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Mon, 23 Mar 2009 20:32:41 +0100 Subject: [M3devel] About 404 http https error at opencm3.net elegosoft.com modula3.org In-Reply-To: <577748.77637.qm@web24706.mail.ird.yahoo.com> References: <577748.77637.qm@web24706.mail.ird.yahoo.com> Message-ID: <20090323203241.25qdopfjksocc4s8@mail.elegosoft.com> Hello All, birch.elego.de experienced a hardware failure today. I am in the process of rebuilding and restoring now. I hope to get web services up soon. Thanks for your patience. -Michael Anderson Quoting "Daniel Alejandro Benavides D." : > Hi all: > just want to make sure I can't access? the web pages of the server. > Is it working well ? > on https://elegosoft.com/ > or http://elegosoft.com/ > I got 404 error from the common urls > Not Found > The requested URL / was not found on this server. > > Apache Server at www.opencm3.net Port 80 > > However server does respond to ICMP requests and I guess other > services (including http) > ping opencm3.net > PING opencm3.net (88.198.39.217) 56(84) bytes of data. > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=1 ttl=54 time=117 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=2 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=3 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=4 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=5 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=6 ttl=54 time=115 ms > > --- opencm3.net ping statistics --- > 6 packets transmitted, 6 received, 0% packet loss, time 4998ms > rtt min/avg/max/mdev = 115.483/115.854/117.030/0.578 ms > > And I can't get any web page on http or https > > wget opencm3.net > --12:08:02--? http://opencm3.net/ > ?????????? => `index.html' > Resolving opencm3.net... 88.198.39.217 > Connecting to opencm3.net|88.198.39.217|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 12:08:02 ERROR 404: Not Found. > > > > wget https://opencm3.net --no-check-certificate > --12:13:25--? https://opencm3.net/ > ?????????? => `index.html' > Resolving opencm3.net... 88.198.39.217 > Connecting to opencm3.net|88.198.39.217|:443... connected. > WARNING: Certificate verification error for opencm3.net: self signed > certificate in certificate chain > WARNING: certificate common name `wiki.elegosoft.com' doesn't match > requested host name `opencm3.net'. > HTTP request sent, awaiting response... 404 Not Found > 12:13:25 ERROR 404: Not Found. > > > I can't rememeber now my elego.de user passsword so I can't diagnose > further more. > Can any one check further on the web server? > > Thanks in advance > > > > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Mon Mar 23 21:57:54 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Mar 2009 13:57:54 -0700 (PDT) Subject: [M3devel] About 404 http https error at opencm3.net elegosoft.com modula3.org In-Reply-To: <20090323203241.25qdopfjksocc4s8@mail.elegosoft.com> Message-ID: <917618.29859.qm@web24712.mail.ird.yahoo.com> Hi: thanks Michael, please if you can give us a note when is solved. Just to know. Thanks in advance --- El lun, 23/3/09, Michael Anderson escribi?: De: Michael Anderson Asunto: Re: [M3devel] About 404 http https error at opencm3.net elegosoft.com modula3.org Para: m3devel at elegosoft.com Fecha: lunes, 23 marzo, 2009 2:32 Hello All, birch.elego.de experienced a hardware failure today. I am in the process of rebuilding and restoring now. I hope to get web services up soon. Thanks for your patience. -Michael Anderson Quoting "Daniel Alejandro Benavides D." : > Hi all: > just want to make sure I can't access? the web pages of the server. Is it working well ? > on https://elegosoft.com/ > or http://elegosoft.com/ > I got 404 error from the common urls > Not Found > The requested URL / was not found on this server. > > Apache Server at www.opencm3.net Port 80 > > However server does respond to ICMP requests and I guess other services (including http) > ping opencm3.net > PING opencm3.net (88.198.39.217) 56(84) bytes of data. > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=1 ttl=54 time=117 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=2 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=3 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=4 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=5 ttl=54 time=115 ms > 64 bytes from birch.elego.de (88.198.39.217): icmp_seq=6 ttl=54 time=115 ms > > --- opencm3.net ping statistics --- > 6 packets transmitted, 6 received, 0% packet loss, time 4998ms > rtt min/avg/max/mdev = 115.483/115.854/117.030/0.578 ms > > And I can't get any web page on http or https > > wget opencm3.net > --12:08:02--? http://opencm3.net/ > ?????????? => `index.html' > Resolving opencm3.net... 88.198.39.217 > Connecting to opencm3.net|88.198.39.217|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 12:08:02 ERROR 404: Not Found. > > > > wget https://opencm3.net --no-check-certificate > --12:13:25--? https://opencm3.net/ > ?????????? => `index.html' > Resolving opencm3.net... 88.198.39.217 > Connecting to opencm3.net|88.198.39.217|:443... connected. > WARNING: Certificate verification error for opencm3.net: self signed certificate in certificate chain > WARNING: certificate common name `wiki.elegosoft.com' doesn't match requested host name `opencm3.net'. > HTTP request sent, awaiting response... 404 Not Found > 12:13:25 ERROR 404: Not Found. > > > I can't rememeber now my elego.de user passsword so I can't diagnose further more. > Can any one check further on the web server? > > Thanks in advance > > > > --Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Mar 25 08:31:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 25 Mar 2009 08:31:58 +0100 Subject: [M3devel] m3 CVS? In-Reply-To: References: Message-ID: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> Quoting Jay : > > Any idea when CVS will be back? > And what state it will be in? There was a bad disk crash on birch, and some of the backups (rootfs) seem to be unusable, so it's taking longer than expected. All CM3 CVS data should be save. Sorry for the service interruption, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Wed Mar 25 14:52:34 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 09:52:34 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> Message-ID: <20090325135234.GA16351@topoi.pooq.com> On Wed, Mar 25, 2009 at 08:31:58AM +0100, Olaf Wagner wrote: > Quoting Jay : > > > > >Any idea when CVS will be back? > >And what state it will be in? > > There was a bad disk crash on birch, and some of the backups (rootfs) > seem to be unusable, so it's taking longer than expected. Ouch! I've had one of those. Now I use a RAID-1, regular backups onto USB drives I keep disconnected from the computer, and check important source code into a distributed revision control system with a complete copy of the archive on a remote site. All in all, three different backup technologies. Am I too paranoid? > All CM3 CVS data should be save. That's good. It looks as if you've been paranoid enough. > > Sorry for the service interruption, > > Olaf I just tried to access monotone.ca. ping monotone.ca works, but http: access is quite dead. At this point, I speculate it would be nice to have another server somewhere else in the world. When things are back together, I could experiment with setting up a monotone server with the same content and history as the Modula 3 CVS, if you like. monotone is a distributed version control system that is reported to have good interoperation with CVS. It would be interesting to test if that is actually true. No, you wouldn't have to switch from CVS to monotone if I did that. -- hendrik From hendrik at topoi.pooq.com Wed Mar 25 15:08:46 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 10:08:46 -0400 Subject: [M3devel] Am I experiencing garbage collection? Message-ID: <20090325140846.GA16459@topoi.pooq.com> I'm working on a pixel-based image edotor with variable-sized pixels. (That weirdness was the one of the simplest things that could possibly work for an esoteric application.) I implemented mouse-tracking according to instructins in the Trestle manual, and it works, except for small gaps that occur every few seconds. They correspond to mouse-deafness intervals of maybe a hundredth or a twentieth of a second or so. But in the course of building my pizel map, I find myself allocating storage dynamically. Could I be experiencing garbage-collection delays? -- hendrik From wagner at elegosoft.com Wed Mar 25 16:35:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 25 Mar 2009 16:35:37 +0100 Subject: [M3devel] m3 CVS? In-Reply-To: <20090325135234.GA16351@topoi.pooq.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> Message-ID: <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Mar 25, 2009 at 08:31:58AM +0100, Olaf Wagner wrote: >> Quoting Jay : >> > I just tried to access monotone.ca. ping monotone.ca works, but http: > access is quite dead. > > At this point, I speculate it would be nice to have another server > somewhere else in the world. The CM3 repository is replicated to several other machines every night via CVSup. But the other machines are not publicly accessible. > When things are back together, I could experiment with setting up a > monotone server with the same content and history as the Modula 3 CVS, > if you like. monotone is a distributed version control system that is > reported to have good interoperation with CVS. It would be interesting > to test if that is actually true. Yes. > No, you wouldn't have to switch from CVS to monotone if I did that. No objections at all. I wouldn't object to Subversion, too, if somebody would do all the work and provide the equivalent infrastructure. It's just that I don't see that we really need it. I'd like to see Hudson instead of Tinderbox though... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Wed Mar 25 15:45:06 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 10:45:06 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> Message-ID: <20090325144505.GA16526@topoi.pooq.com> On Wed, Mar 25, 2009 at 04:35:37PM +0100, Olaf Wagner wrote: > > >When things are back together, I could experiment with setting up a > >monotone server with the same content and history as the Modula 3 CVS, > >if you like. monotone is a distributed version control system that is > >reported to have good interoperation with CVS. It would be interesting > >to test if that is actually true. > > Yes. Further googling reveals that the encouraging messages about interoperability are a few years old, and refer to a non-trunk development branch. The next step would seem to be to figure out what the status of that work is now. I.m no longer quite as optimistic. There does seem to be a one-way conversino from CVS to monotone, but that's not what I'm looking for. -- hendrik > I'd like to see Hudson instead of Tinderbox though... What are these? -- hendrik From wagner at elegosoft.com Wed Mar 25 17:18:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 25 Mar 2009 17:18:55 +0100 Subject: [M3devel] m3 CVS? In-Reply-To: <20090325144505.GA16526@topoi.pooq.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> Message-ID: <20090325171855.24zpbw1lsg048g4c@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Wed, Mar 25, 2009 at 04:35:37PM +0100, Olaf Wagner wrote: > >> I'd like to see Hudson instead of Tinderbox though... > > What are these? Continuous integration or regression test frameworks. We currently use tinderbox on birch, but that hasn't really convinced me, though it's way better than nothing. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Wed Mar 25 21:16:00 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 25 Mar 2009 21:16:00 +0100 (CET) Subject: [M3devel] [Fwd: Prentice-Hall says no] In-Reply-To: <49C23A1F.1070800@bellsouth.net> References: <49C23A1F.1070800@bellsouth.net> Message-ID: The current lawsuit against Google might end with a settlement which may allow Google to make books available online that are out of print. Would this be a solution? http://www.googlebooksettlement.com/ From jay.krell at cornell.edu Wed Mar 25 22:44:11 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 25 Mar 2009 21:44:11 +0000 Subject: [M3devel] m3 CVS? In-Reply-To: <20090325144505.GA16526@topoi.pooq.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> Message-ID: /Apparently/ cvs to svn conversion is pretty easy and good. svn is not "distributed", but at least it automatically keeps originals locally so you can diff without accessing the server. And browsing history where multiple files are commited in one change works, vs. cvs. svn branching doesn't really work, but that's probaby ok. Maybe they have fixed it, but for a long time, svn would not know what changes had been moved to which branches, a pretty basic requirement. Perforce does this perfectly. Perforce might be a good option if being open source lets us get it for free. Otherwise it is expensive. It is an excellent product. svn is at least somewhat better than cvs. - Jay ---------------------------------------- > Date: Wed, 25 Mar 2009 10:45:06 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3 CVS? > > On Wed, Mar 25, 2009 at 04:35:37PM +0100, Olaf Wagner wrote: >> >>>When things are back together, I could experiment with setting up a >>>monotone server with the same content and history as the Modula 3 CVS, >>>if you like. monotone is a distributed version control system that is >>>reported to have good interoperation with CVS. It would be interesting >>>to test if that is actually true. >> >> Yes. > > Further googling reveals that the encouraging messages about > interoperability are a few years old, and refer to a non-trunk > development branch. The next step would seem to be to figure out what > the status of that work is now. I.m no longer quite as optimistic. > There does seem to be a one-way conversino from CVS to monotone, but > that's not what I'm looking for. > > -- hendrik > >> I'd like to see Hudson instead of Tinderbox though... > > What are these? > > -- hendrik From hosking at cs.purdue.edu Thu Mar 26 00:15:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Mar 2009 10:15:12 +1100 Subject: [M3devel] Fwd: Output from "cron" command References: <200903251030.n2PAUN5M001118@niagara.cs.purdue.edu> Message-ID: <3637619A-EFC4-4E00-A3E9-FDA11D8050E6@cs.purdue.edu> Something wrong with birch? Why would I suddenly be getting sudo errors? Begin forwarded message: > From: Tony Hosking > Date: 25 March 2009 21:30:23 GMT+11:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > Cannot access /usr/cvs/CVSROOT > No such file or directory > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-03-25-10-30-07 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090325-063009-dWaOYb/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.03.25 06:30:09 -- checkout in progress. > > We trust you have received the usual lecture from the local System > Administrator. It usually boils down to these three things: > > #1) Respect the privacy of others. > #2) Think before you type. > #3) With great power comes great responsibility. > > Password: > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090325-063009-dWaOYb ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > Cannot access /usr/cvs/CVSROOT > No such file or directory > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-03-25-10-30-17 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090325-063019-Okaiac/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.03.25 06:30:19 -- checkout in progress. > > We trust you have received the usual lecture from the local System > Administrator. It usually boils down to these three things: > > #1) Respect the privacy of others. > #2) Think before you type. > #3) With great power comes great responsibility. > > Password: > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090325-063019-Okaiac ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 26 00:23:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Mar 2009 10:23:24 +1100 Subject: [M3devel] Am I experiencing garbage collection? In-Reply-To: <20090325140846.GA16459@topoi.pooq.com> References: <20090325140846.GA16459@topoi.pooq.com> Message-ID: It is possible that you are experiencing delays, though I am surprised that you have user-noticeable delays. Do you have a demo I can try? You could also try turning of GC (@M3nogc) and see if the delays are no longer there. On 26 Mar 2009, at 01:08, hendrik at topoi.pooq.com wrote: > I'm working on a pixel-based image edotor with variable-sized pixels. > (That weirdness was the one of the simplest things that could possibly > work for an esoteric application.) > > I implemented mouse-tracking according to instructins in the Trestle > manual, and it works, except for small gaps that occur every few > seconds. They correspond to mouse-deafness intervals of maybe a > hundredth or a twentieth of a second or so. > > But in the course of building my pizel map, I find myself allocating > storage dynamically. Could I be experiencing garbage-collection > delays? > > -- hendrik From hendrik at topoi.pooq.com Wed Mar 25 23:54:21 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 18:54:21 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> Message-ID: <20090325225421.GB17118@topoi.pooq.com> On Wed, Mar 25, 2009 at 09:44:11PM +0000, Jay wrote: > > /Apparently/ cvs to svn conversion is pretty easy and good. conversion from cvs to monotone works, too. It's converting back from monotone to cvs that is apparently a problem. But I still haven't heard the current status of the cvssync branch of monotone development. That's the branch where monotone allegedly worked both ways with CVS. > > svn is not "distributed", but at least it automatically keeps > originals locally so you can diff without accessing the server. Being distributed, monotone keeps originals locally, too. And monotone will diff them for you. > > And browsing history where multiple files are commited > in one change works, vs. cvs. As does monotone, and many current VCSs. > > svn branching doesn't really work, but that's probaby ok. monotone branching does work. > Maybe they have fixed it, but for a long time, svn > would not know what changes had been moved to which branches, > a pretty basic requirement. Perforce does this perfectly. > Perforce might be a good option if being open source lets > us get it for free. Otherwise it is expensive. It is an > excellent product. > > svn is at least somewhat better than cvs. In http://gravityboy.livejournal.com/39755.html, gravityboy says : I'm really tired of people pushing the adoption of svn because it's a : better CVS. The only people who that argument hasn't swayed are those : who don't care what vcs they use, and that's because they don't : care about the argument. Despite its name, svn is the status quo now, : so do try to compare it to systems that it hasn't already made obsolete. Apparently he'd like to have svn compared to newer VCSs instead of obsolete ones. In case you don't know, gravityboy is one of the X developers that got X doing reasonable autodetection of hardware. I'm in awe of what that group accomplished. The thing I really like about monotone is that the developers are absolutely paranoid about data loss. It refuses to sync with broken repositories, and spends extra time on internal consistency checks on the data base during sync. This provides some protection against corruption due to bits dropped on hard disk and such. They have a rigorous and pragmatic attitude about correctness that I see in the Modula 3 design, too. Except that they developed monotone using C++. -- hendrik > > - Jay From hendrik at topoi.pooq.com Thu Mar 26 00:00:54 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 19:00:54 -0400 Subject: [M3devel] Am I experiencing garbage collection? In-Reply-To: References: <20090325140846.GA16459@topoi.pooq.com> Message-ID: <20090325230053.GC17118@topoi.pooq.com> On Thu, Mar 26, 2009 at 10:23:24AM +1100, Tony Hosking wrote: > It is possible that you are experiencing delays, though I am surprised > that you have user-noticeable delays. Do you have a demo I can try? > You could also try turning of GC (@M3nogc) and see if the delays are > no longer there. I don't notice a delay -- I notice small gaps in the trail of pixels activated by the mouse rolling over them. From the size of the gap I estimate it might be as long as a twentieth of a secind, but it's probably more like a hundredth. I didn't use a stopwatch to time it. And I do build a fair amount of data structure per pixel. I'm probably going to have to change it -- but only once I've got some experience how the application actually works. At the moment I've only ot a few bits and pieces. That option @M3nogc -- do I put it on the command line when I execute? -- hendrik From hendrik at topoi.pooq.com Thu Mar 26 00:14:38 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 19:14:38 -0400 Subject: [M3devel] Am I experiencing garbage collection? In-Reply-To: <20090325230053.GC17118@topoi.pooq.com> References: <20090325140846.GA16459@topoi.pooq.com> <20090325230053.GC17118@topoi.pooq.com> Message-ID: <20090325231437.GA17379@topoi.pooq.com> On Wed, Mar 25, 2009 at 07:00:54PM -0400, hendrik at topoi.pooq.com wrote: > On Thu, Mar 26, 2009 at 10:23:24AM +1100, Tony Hosking wrote: > > It is possible that you are experiencing delays, though I am surprised > > that you have user-noticeable delays. Do you have a demo I can try? > > You could also try turning of GC (@M3nogc) and see if the delays are > > no longer there. > > That option @M3nogc -- do I put it on the command line when I execute? Thanks. Running ./LINUXLIBC6/Main @M3nogc instead of ./LINUXLIBC6/Main gives me the same momentary gaps. So if that's how you shut off the garbage collector, it's not the garbage collector. Perhaps some other process is stealing centiseconds now and then. -- hendrik From hosking at cs.purdue.edu Thu Mar 26 01:26:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Mar 2009 11:26:55 +1100 Subject: [M3devel] Am I experiencing garbage collection? In-Reply-To: <20090325231437.GA17379@topoi.pooq.com> References: <20090325140846.GA16459@topoi.pooq.com> <20090325230053.GC17118@topoi.pooq.com> <20090325231437.GA17379@topoi.pooq.com> Message-ID: <27EB1179-F121-4DCA-8B4C-91136EA80DF6@cs.purdue.edu> That's good (from my perspective) because I worried the collector was getting in the way. Looks like something else perhaps. I suggest profiling somehow to get a sense as to what is interrupting you. Are you running with pthreads? On 26 Mar 2009, at 10:14, hendrik at topoi.pooq.com wrote: > On Wed, Mar 25, 2009 at 07:00:54PM -0400, hendrik at topoi.pooq.com > wrote: >> On Thu, Mar 26, 2009 at 10:23:24AM +1100, Tony Hosking wrote: >>> It is possible that you are experiencing delays, though I am >>> surprised >>> that you have user-noticeable delays. Do you have a demo I can try? >>> You could also try turning of GC (@M3nogc) and see if the delays are >>> no longer there. >> >> That option @M3nogc -- do I put it on the command line when I >> execute? > > Thanks. > > Running > ./LINUXLIBC6/Main @M3nogc > instead of > ./LINUXLIBC6/Main > gives me the same momentary gaps. So if that's how you shut off the > garbage collector, it's not the garbage collector. Perhaps some other > process is stealing centiseconds now and then. > > -- hendrik From hendrik at topoi.pooq.com Thu Mar 26 01:43:07 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 25 Mar 2009 20:43:07 -0400 Subject: [M3devel] Am I experiencing garbage collection? In-Reply-To: <27EB1179-F121-4DCA-8B4C-91136EA80DF6@cs.purdue.edu> References: <20090325140846.GA16459@topoi.pooq.com> <20090325230053.GC17118@topoi.pooq.com> <20090325231437.GA17379@topoi.pooq.com> <27EB1179-F121-4DCA-8B4C-91136EA80DF6@cs.purdue.edu> Message-ID: <20090326004307.GA17514@topoi.pooq.com> On Thu, Mar 26, 2009 at 11:26:55AM +1100, Tony Hosking wrote: > That's good (from my perspective) because I worried the collector was > getting in the way. Looks like something else perhaps. I suggest > profiling somehow to get a sense as to what is interrupting you. Are > you running with pthreads? I don't know whether I'm using pthreads. I just grabbed the source from the web site and compiled for a while. Critical Mass Modula-3 version d5.7.0 last updated: 2008-03-16 compiled: 2008-04-09 01:32:11 configuration: /usr/local/cm3/bin/cm3.cfg Anyway, pthreads or not, my process isn't the only one on the machine. And there's easy application-dependent workarounds. And some changes I have to make for other reasons will probably bypass the problem I'm having now anyway. Let me say that your surprise at the thought that the garbage collector could be causing these interruptions is a strong indication that I won't have to worry about collection delays. -- hendrik From jay.krell at cornell.edu Thu Mar 26 03:08:00 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 26 Mar 2009 02:08:00 +0000 Subject: [M3devel] m3 CVS? In-Reply-To: <20090325225421.GB17118@topoi.pooq.com> References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> Message-ID: > > svn is at least somewhat better than cvs. > > In http://gravityboy.livejournal.com/39755.html, gravityboy says > > : I'm really tired of people pushing the adoption of svn because it's a > : better CVS. The only people who that argument hasn't swayed are those That's ambiguous to me. He isn't clearly opposed to adopting svn over cvs, but svn over anything else. It doesn't matter what I think, but I'm definitely not opposed to monotone. Its marketing material reads among the best (seriously). I'm not volunteering to do any conversion, and I'm sure I (and others) will grumble no matter how painless switching clients is, but I'm pretty sure there are gains to be had and ignore at least my grumbling. I really don't like the web interface to CVS in particular. It doesn't let me identify "change sets" and view their diffs, I have to root around to all the files. Tinderbox does address this, on the side. (You would have to be sure, whatever replacement/conversion, included a web interface, anonymous read-only access, Tinderbox-or-other interop, etc.; imho you don't have to deliver all at once.) The source control systems that use "databases", which I think monotone does, do they interact poorly with backup (in particular, whatever backup Elegosoft uses)? You know -- an incremental backup system that looks at file times/sizes would end up always copying the entire thing. Even so, "databases" can be a good thing.. I understand that "two way migration" lets people keep using either system, but I'm not sure that's worthwhile. On the other hand, if "the new way" is read/write, and a "cvs mirror" is read only, except for some blessed mirroring server, that should be fairly easy and have some value. That can also be a way to ease the transition wrt anonymous read-only access, Tinderbox interop, etc. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 26 03:11:53 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 26 Mar 2009 02:11:53 +0000 Subject: [M3devel] Am I experiencing garbage collection? In-Reply-To: <20090326004307.GA17514@topoi.pooq.com> References: <20090325140846.GA16459@topoi.pooq.com> <20090325230053.GC17118@topoi.pooq.com> <20090325231437.GA17379@topoi.pooq.com> <27EB1179-F121-4DCA-8B4C-91136EA80DF6@cs.purdue.edu> <20090326004307.GA17514@topoi.pooq.com> Message-ID: pthreads is the default, and I suspect it is the only thing that works currently. I started debugging why it wasn't working on PPC_LINUX, the reason seemed to be that the initial thread was used before it was allocated, but I stopped debugging and just switched to pthreads. NetBSD/x86 didn't work as it was -- didn't even compile I think -- so I switched it to pthreads as well. (I'll have a NetBSD/x86 archive up very soon.) I might go back and debug these again.. - Jay > Date: Wed, 25 Mar 2009 20:43:07 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Am I experiencing garbage collection? > > On Thu, Mar 26, 2009 at 11:26:55AM +1100, Tony Hosking wrote: > > That's good (from my perspective) because I worried the collector was > > getting in the way. Looks like something else perhaps. I suggest > > profiling somehow to get a sense as to what is interrupting you. Are > > you running with pthreads? > > I don't know whether I'm using pthreads. I just grabbed the source > from the web site and compiled for a while. > > Critical Mass Modula-3 version d5.7.0 > last updated: 2008-03-16 > compiled: 2008-04-09 01:32:11 > configuration: /usr/local/cm3/bin/cm3.cfg > > Anyway, pthreads or not, my process isn't the only one on the machine. > > And there's easy application-dependent workarounds. And some changes I > have to make for other reasons will probably bypass the problem > I'm having now anyway. > > Let me say that your surprise at the thought that the garbage collector > could be causing these interruptions is a strong indication that I > won't have to worry about collection delays. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 26 11:04:50 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 26 Mar 2009 10:04:50 +0000 Subject: [M3devel] ports with versions in their names? Message-ID: These platforms..NetBSD2i386, FreeBSD4..in particular because they identify old versions, should we just pretend they are "I386_NETBSD" and "I386_FREEBSD"? Introduce new platforms with those names? Current FreeBSD is 7.1, though I know 4.0 might be more popular than it sounds. There is not likely anything any longer version specific in the source to these ports, and possibly not even in the binaries. And if there is anything version-specific in the binaries, removing it might requiring building on the particular host, or at least capturing their sysroot and building cross gcc/ld/gas. I don't know if the "6" in "LINUXLIBC6" still makes sense. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Mar 26 14:22:17 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 26 Mar 2009 14:22:17 +0100 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <3637619A-EFC4-4E00-A3E9-FDA11D8050E6@cs.purdue.edu> References: <200903251030.n2PAUN5M001118@niagara.cs.purdue.edu> <3637619A-EFC4-4E00-A3E9-FDA11D8050E6@cs.purdue.edu> Message-ID: <20090326142217.po81adh5yccs0kck@mail.elegosoft.com> Quoting Tony Hosking : > Something wrong with birch? Why would I suddenly be getting sudo errors? Birch has had a root file system disk crash. Michael Anderson is taking care. I just asked him to write a short status mail about the recovery activites and when all services should be available again. All CVS data should be safe, but may not yet be online again. Sorry for the inconveniences, Olaf > Begin forwarded message: > >> From: Tony Hosking >> Date: 25 March 2009 21:30:23 GMT+11:00 >> To: hosking at cs.purdue.edu >> Subject: Output from "cron" command >> >> Your "cron" job on niagara.cs.purdue.edu >> $HOME/cm3/scripts/regression/cron.sh >> >> produced the following output: >> >> Cannot access /usr/cvs/CVSROOT >> No such file or directory >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-03-25-10-30-07 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara release-build" >> >> creating log file /tmp/build-cm3-20090325-063009-dWaOYb/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.03.25 06:30:09 -- checkout in progress. >> >> We trust you have received the usual lecture from the local System >> Administrator. It usually boils down to these three things: >> >> #1) Respect the privacy of others. >> #2) Think before you type. >> #3) With great power comes great responsibility. >> >> Password: >> Error: Sending buildlog failed! >> removing build tree /tmp/build-cm3-20090325-063009-dWaOYb ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> >> Cannot access /usr/cvs/CVSROOT >> No such file or directory >> TESTHOSTNAME=niagara >> WS=/homes/hosking/work/cm3-ws/niagara-2009-03-25-10-30-17 >> LASTREL=5.4.0 >> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 >> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok >> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok >> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current >> CM3_OSTYPE=POSIX >> CM3_TARGET=SOLgnu >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> CM3CVSSERVER=birch.elegosoft.com >> CM3CVSROOT=birch.elegosoft.com:/usr/cvs >> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz >> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz >> testing ssh birch.elegosoft.com.. >> ssh birch.elegosoft.com ok >> Building cm3. >> Tinderbox Tree: "cm3" >> Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" >> >> creating log file /tmp/build-cm3-20090325-063019-Okaiac/log.txt >> >> --- >> >> checkout, compile and test of cm3 ... >> 2009.03.25 06:30:19 -- checkout in progress. >> >> We trust you have received the usual lecture from the local System >> Administrator. It usually boils down to these three things: >> >> #1) Respect the privacy of others. >> #2) Think before you type. >> #3) With great power comes great responsibility. >> >> Password: >> Error: Sending buildlog failed! >> removing build tree /tmp/build-cm3-20090325-063019-Okaiac ... >> cleaning CM3 workspaces... >> /homes/hosking/work/cm3-ws/niagara-* >> >> cleaning regression test log files... >> /homes/hosking/tmp/cm3/niagara/cm3-rlog-* >> >> cleaning m3test log files... >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr >> >> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract >> >> cleaning snapshot files... >> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz >> >> cleaning package reports... >> /tmp/cm3-pkg-report-SOLgnu-*.html >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From michael.anderson at elego.de Fri Mar 27 06:07:52 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 27 Mar 2009 06:07:52 +0100 Subject: [M3devel] Modula3.org Server Crash Message-ID: <20090327060752.unn6c683wo88kww0@mail.elegosoft.com> Hello Modula3 Users, Developers, Earlier this week, our Modula3 development and web server birch.elegosoft.com suffered a sudden and catastrophic hard drive failure, coinciding with a problem of unrelated origins which rendered a portion of our filesystem backups unusable. The status of birch now: -The cm3 cvs repository is safe, intact, and back online. The data is up to date, but configuration is not quite as current and will need some tweaking. Commit email notifications aren't working quite right yet. If anybody happens to have a halfway recently checked-out /usr/local/CVSROOT, I'd love to get my hands on it. -The cvs pserver is available and cvsweb is up. -The website is up, albeit with a considerable number of broken links, which will be repaired as other services and data come online. -I'll be working on Tinderbox next. I'm hoping to get everything halfway back to normal by early next week. Sorry for the chaos, thanks for being patient. -Michael Anderson -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Mar 27 08:23:37 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Mar 2009 08:23:37 +0100 Subject: [M3devel] ports with versions in their names? In-Reply-To: References: Message-ID: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> Quoting Jay : > > These platforms..NetBSD2i386, FreeBSD4..in particular > because they identify old versions, should we just > pretend they are "I386_NETBSD" and "I386_FREEBSD"? > > Introduce new platforms with those names? The names seem OK; if you want to rename, this will of course cause some trouble, but I wouldn't object. Perhaps adding them and then slowly phasing out the old platforms will work best. > Current FreeBSD is 7.1, though I know 4.0 might be > more popular than it sounds. FreeBSD 4 perhaps still has its users, as has FreeBSD6 (am still running that myself). We'll need to provide different binary archives for those platforms then (further differentiation in archive names is needed). > There is not likely anything any longer version specific > in the source to these ports, and possibly not even in the binaries. I'd doubt that. At least FreeBSD has always changed its APIs and even ABIs between major releases. Recompilation of C sources _will_ be needed. > And if there is anything version-specific in the binaries, > removing it might requiring building on the particular host, > or at least capturing their sysroot and building cross gcc/ld/gas. > > I don't know if the "6" in "LINUXLIBC6" still makes sense. Perhaps just reuse the long obsolet LINUX then? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Fri Mar 27 21:33:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 27 Mar 2009 13:33:24 -0700 Subject: [M3devel] ports with versions in their names? In-Reply-To: Your message of "Fri, 27 Mar 2009 08:23:37 BST." <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> Message-ID: <200903272033.n2RKXOci055168@camembert.async.caltech.edu> Olaf Wagner writes: >Quoting Jay : > >> >> These platforms..NetBSD2i386, FreeBSD4..in particular >> because they identify old versions, should we just >> pretend they are "I386_NETBSD" and "I386_FREEBSD"? >> >> Introduce new platforms with those names? > >The names seem OK; if you want to rename, this will of course >cause some trouble, but I wouldn't object. Perhaps adding >them and then slowly phasing out the old platforms will work >best. > >> Current FreeBSD is 7.1, though I know 4.0 might be >> more popular than it sounds. > >FreeBSD 4 perhaps still has its users, as has FreeBSD6 (am still >running that myself). >We'll need to provide different binary archives for those platforms >then (further differentiation in archive names is needed). > >> There is not likely anything any longer version specific >> in the source to these ports, and possibly not even in the binaries. > >I'd doubt that. At least FreeBSD has always changed its APIs and even >ABIs between major releases. Recompilation of C sources _will_ be >needed. > Hi M3ers, As I think I've mentioned before, FreeBSD tends to be very well backward-compatible. If you have compat libraries installed that is. What this means is that you can take an old compiler binary and generate code that will run on the newer system. You cannot go backwards! So while you might be able to install SRC M3 for FreeBSD2 on a new system, you can't expect a FreeBSD7 binary dist to work even on a FreeBSD 6.x system. This is very different from the situation on Linux where things to break somewhat gradually in both directions. I still run at least one machine that's 4.11 and I use the exact same compiler binaries on 5.5. I'd be happy to volunteer to put together a binary distribution for FreeBSD4 when there's a new release of CM3. Mika P.S. of course my comments apply only to a single architecture. You can't go from FreeBSD2 on i386 to FreeBSD6 on amd64, I don't think. From jay.krell at cornell.edu Sat Mar 28 08:08:10 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 28 Mar 2009 07:08:10 +0000 Subject: [M3devel] ports with versions in their names? In-Reply-To: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> References: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> Message-ID: > > I don't know if the "6" in "LINUXLIBC6" still makes sense. > > Perhaps just reuse the long obsolet LINUX then? > > Olaf Given {AMD64,SPARC32,SPARC64,PPC,potentially PPC64,ALPHA,ARM,SH,MIPS32,MIPS64}_LINUX, doesn't it seem wrong to use plain "LINUX"? I know I know most of the world hasn't seen or heard of anything besides x86.. and "64bit" means AMD64... if we just had "LINUX" and "LINUX64" hardly anyone would see a problem.. More later.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Mar 28 11:11:50 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 28 Mar 2009 11:11:50 +0100 Subject: [M3devel] ports with versions in their names? In-Reply-To: References: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> Message-ID: <20090328111150.u81eq67aos08scwg@mail.elegosoft.com> Quoting Jay : >> > I don't know if the "6" in "LINUXLIBC6" still makes sense. >> >> Perhaps just reuse the long obsolet LINUX then? > > Given {AMD64,SPARC32,SPARC64,PPC,potentially > PPC64,ALPHA,ARM,SH,MIPS32,MIPS64}_LINUX, doesn't it seem wrong to > use plain "LINUX"? > > I know I know most of the world hasn't seen or heard of anything > besides x86.. and "64bit" means AMD64... if we just had "LINUX" and > "LINUX64" hardly anyone would see a problem.. Sorry, small misunderstanding. I didn't want to omit all architecture/ processor information, just leave out the LIBC6. So perhaps LINUX_MIPS32 or LINUX_AMD64 etc. would suffice? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Mar 28 13:04:01 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 28 Mar 2009 12:04:01 +0000 Subject: [M3devel] ports with versions in their names? In-Reply-To: <20090328111150.u81eq67aos08scwg@mail.elegosoft.com> References: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> <20090328111150.u81eq67aos08scwg@mail.elegosoft.com> Message-ID: Tony has established consistency around ARCH_KERNEL. I386_DARWIN PPC_DARWIN AMD64_DARWIN I followed that -- I like it and Tony said to -- but have been putting "32" in things, like: AMD64_FREEBSD AMD64_LINUX SPARC32_LINUX SPARC64_LINUX SPARC64_SOLARIS PPC32_OPENBSD I386_SOLARIS MIP64_OPENBSD etc. I realize some platforms had it the other the other way around. NetBSDi386v2 and a bunch in the ezm3 distribution and FSBD_ALPHA. But, I carefully only asked about platforms with versions in their names, which are clearly dubious, not about the more general issue of naming stuff. If Linux is "permanently" on libc 6.x, like the kernel is permanently 2.6.x, then my question/argument holds less/no water -- that's why I stated that way and made it "stronger" "against" NetBSD and FreeBSD, where I know the version history much better. (I understand, I think, part of the history. I think Linux had its own C runtime, and that got up to around version 5.x. And then there was a big switch to glibc, since that came after "linux libc 5.x", natural to call it 6. Though in reality I think the glibc version is 2.x..maybe it should have been called LINUXGLIBC..? It is mostly moot now, that's not likely to be a name introduced at this point..though there are currently multiple viable C runtimes on Linux -- uclibc, newlib, dietlibc..) - Jay > Date: Sat, 28 Mar 2009 11:11:50 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] ports with versions in their names? > > Quoting Jay : > > >> > I don't know if the "6" in "LINUXLIBC6" still makes sense. > >> > >> Perhaps just reuse the long obsolet LINUX then? > > > > Given {AMD64,SPARC32,SPARC64,PPC,potentially > > PPC64,ALPHA,ARM,SH,MIPS32,MIPS64}_LINUX, doesn't it seem wrong to > > use plain "LINUX"? > > > > I know I know most of the world hasn't seen or heard of anything > > besides x86.. and "64bit" means AMD64... if we just had "LINUX" and > > "LINUX64" hardly anyone would see a problem.. > > Sorry, small misunderstanding. I didn't want to omit all architecture/ > processor information, just leave out the LIBC6. So perhaps > LINUX_MIPS32 or LINUX_AMD64 etc. would suffice? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Mar 28 14:48:52 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 28 Mar 2009 13:48:52 +0000 Subject: [M3devel] Modula3.org Server Crash In-Reply-To: <20090327060752.unn6c683wo88kww0@mail.elegosoft.com> References: <20090327060752.unn6c683wo88kww0@mail.elegosoft.com> Message-ID: Commit seems to work (I get email) but also tells me: cvs commit: warning: cannot open history file `/usr/cvs/CVSROOT/history' for wri te: Permission denied cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. - Jay ---------------------------------------- > Date: Fri, 27 Mar 2009 06:07:52 +0100 > From: michael.anderson at elego.de > To: m3devel at elegosoft.com; m3announce at elegosoft.com; m3commit at elegosoft.com > Subject: [M3devel] Modula3.org Server Crash > > Hello Modula3 Users, Developers, > > Earlier this week, our Modula3 development and web server > birch.elegosoft.com suffered a sudden and catastrophic hard drive > failure, coinciding with a problem of unrelated origins which rendered > a portion of our filesystem backups unusable. > > The status of birch now: > > -The cm3 cvs repository is safe, intact, and back online. The data is > up to date, but configuration is not quite as current and will need > some tweaking. Commit email notifications aren't working quite right > yet. If anybody happens to have a halfway recently checked-out > /usr/local/CVSROOT, I'd love to get my hands on it. > > -The cvs pserver is available and cvsweb is up. > > -The website is up, albeit with a considerable number of broken links, > which will be repaired as other services and data come online. > > -I'll be working on Tinderbox next. > > I'm hoping to get everything halfway back to normal by early next week. > Sorry for the chaos, thanks for being patient. > > -Michael Anderson > > > > > > > -- > Michael Anderson > IT Services & Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Building 12.3 (BIG) room 227 > 13355 Berlin, Germany > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > fax +49 30 23 45 86 95 http://www.elegosoft.com > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > From michael.anderson at elego.de Sat Mar 28 22:00:32 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Sat, 28 Mar 2009 22:00:32 +0100 Subject: [M3devel] Modula3.org Server Crash In-Reply-To: References: <20090327060752.unn6c683wo88kww0@mail.elegosoft.com> Message-ID: <20090328220032.pe5isrci884sgsgs@mail.elegosoft.com> Hi Jay, I've adjusted the perms for the history file. The 'deprecated..' message is annoying but harmless. I will be tuning up the scripts in the course of the next couple of days. -Mike Quoting Jay : > > Commit seems to work (I get email) but also tells me: > > cvs commit: warning: cannot open history file > `/usr/cvs/CVSROOT/history' for wri > te: Permission denied > cvs commit: Using deprecated info format strings. Convert your > scripts to use > the new argument format and remove '1's from your info file format strings. > > - Jay > > > > ---------------------------------------- >> Date: Fri, 27 Mar 2009 06:07:52 +0100 >> From: michael.anderson at elego.de >> To: m3devel at elegosoft.com; m3announce at elegosoft.com; m3commit at elegosoft.com >> Subject: [M3devel] Modula3.org Server Crash >> >> Hello Modula3 Users, Developers, >> >> Earlier this week, our Modula3 development and web server >> birch.elegosoft.com suffered a sudden and catastrophic hard drive >> failure, coinciding with a problem of unrelated origins which rendered >> a portion of our filesystem backups unusable. >> >> The status of birch now: >> >> -The cm3 cvs repository is safe, intact, and back online. The data is >> up to date, but configuration is not quite as current and will need >> some tweaking. Commit email notifications aren't working quite right >> yet. If anybody happens to have a halfway recently checked-out >> /usr/local/CVSROOT, I'd love to get my hands on it. >> >> -The cvs pserver is available and cvsweb is up. >> >> -The website is up, albeit with a considerable number of broken links, >> which will be repaired as other services and data come online. >> >> -I'll be working on Tinderbox next. >> >> I'm hoping to get everything halfway back to normal by early next week. >> Sorry for the chaos, thanks for being patient. >> >> -Michael Anderson >> >> >> >> >> >> >> -- >> Michael Anderson >> IT Services & Support >> >> elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 >> Building 12.3 (BIG) room 227 >> 13355 Berlin, Germany >> >> phone +49 30 23 45 86 96 michael.anderson at elegosoft.com >> fax +49 30 23 45 86 95 http://www.elegosoft.com >> >> Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin >> Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 >> >> -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Mar 28 22:26:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 29 Mar 2009 08:26:16 +1100 Subject: [M3devel] ports with versions in their names? In-Reply-To: References: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> Message-ID: <907C9405-4720-4296-8139-004C72FA2CF2@cs.purdue.edu> LINUXx86? On 28 Mar 2009, at 18:08, Jay wrote: > > > I don't know if the "6" in "LINUXLIBC6" still makes sense. > > > > Perhaps just reuse the long obsolet LINUX then? > > > > Olaf > > > Given {AMD64,SPARC32,SPARC64,PPC,potentially > PPC64,ALPHA,ARM,SH,MIPS32,MIPS64}_LINUX, doesn't it seem wrong to > use plain "LINUX"? > > I know I know most of the world hasn't seen or heard of anything > besides x86.. and "64bit" means AMD64... if we just had "LINUX" and > "LINUX64" hardly anyone would see a problem.. > > More later.. > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Mar 28 22:27:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 29 Mar 2009 08:27:29 +1100 Subject: [M3devel] Fwd: Output from "cron" command References: <200903281030.n2SAUHeI003988@niagara.cs.purdue.edu> Message-ID: <8487DEE3-067D-463C-8C1E-E1FA0F37CC41@cs.purdue.edu> Still problems with tinderbox. Begin forwarded message: > From: Tony Hosking > Date: 28 March 2009 21:30:17 GMT+11:00 > To: hosking at cs.purdue.edu > Subject: Output from "cron" command > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > cvs checkout: warning: cannot open history file `/usr/cvs/CVSROOT/ > history' for write: Permission denied > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-03-28-10-30-04 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20090328-063006-mEayzh/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.03.28 06:30:07 -- checkout in progress. > Content-type: text/html > > > [Sat Mar 28 11:30:09 2009] processmail_builds.cgi: Security Error. > Must not run this program using an effective user id which is > different than the tinderbox user id. id: 10006 id must be 33 > > > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090328-063006-mEayzh ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > > cvs checkout: warning: cannot open history file `/usr/cvs/CVSROOT/ > history' for write: Permission denied > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2009-03-28-10-30-13 > LASTREL=5.4.0 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz > BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz > testing ssh birch.elegosoft.com.. > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20090328-063015-TFa4Mh/log.txt > > --- > > checkout, compile and test of cm3 ... > 2009.03.28 06:30:15 -- checkout in progress. > Content-type: text/html > > > [Sat Mar 28 11:30:16 2009] processmail_builds.cgi: Security Error. > Must not run this program using an effective user id which is > different than the tinderbox user id. id: 10006 id must be 33 > > > Error: Sending buildlog failed! > removing build tree /tmp/build-cm3-20090328-063015-TFa4Mh ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Mar 28 22:31:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 29 Mar 2009 08:31:44 +1100 Subject: [M3devel] ports with versions in their names? In-Reply-To: References: <20090327082337.2oi3lzvruo4w8s0o@mail.elegosoft.com> <20090328111150.u81eq67aos08scwg@mail.elegosoft.com> Message-ID: <01BD9543-D2B1-4A3F-BFAE-5690BF928327@cs.purdue.edu> sounds good to me! On 28 Mar 2009, at 23:04, Jay wrote: > Tony has established consistency around ARCH_KERNEL. > I386_DARWIN > PPC_DARWIN > AMD64_DARWIN > > I followed that -- I like it and Tony said to -- but have been > putting "32" in things, like: > AMD64_FREEBSD > AMD64_LINUX > SPARC32_LINUX > SPARC64_LINUX > SPARC64_SOLARIS > PPC32_OPENBSD > I386_SOLARIS > MIP64_OPENBSD > etc. > > I realize some platforms had it the other the other way around. > NetBSDi386v2 and a bunch in the ezm3 distribution and FSBD_ALPHA. > > > But, I carefully only asked about platforms with versions in their > names, which are clearly dubious, not about the more general issue > of naming stuff. > > > If Linux is "permanently" on libc 6.x, like the kernel is > permanently 2.6.x, then my question/argument holds less/no water -- > that's why I stated that way and made it "stronger" "against" NetBSD > and FreeBSD, where I know the version history much better. > > > (I understand, I think, part of the history. I think Linux had its > own C runtime, and that got up to around version 5.x. And then there > was a big switch to glibc, since that came after "linux libc 5.x", > natural to call it 6. Though in reality I think the glibc version is > 2.x..maybe it should have been called LINUXGLIBC..? It is mostly > moot now, that's not likely to be a name introduced at this > point..though there are currently multiple viable C runtimes on > Linux -- uclibc, newlib, dietlibc..) > > > - Jay > > > > Date: Sat, 28 Mar 2009 11:11:50 +0100 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] ports with versions in their names? > > > > Quoting Jay : > > > > >> > I don't know if the "6" in "LINUXLIBC6" still makes sense. > > >> > > >> Perhaps just reuse the long obsolet LINUX then? > > > > > > Given {AMD64,SPARC32,SPARC64,PPC,potentially > > > PPC64,ALPHA,ARM,SH,MIPS32,MIPS64}_LINUX, doesn't it seem wrong to > > > use plain "LINUX"? > > > > > > I know I know most of the world hasn't seen or heard of anything > > > besides x86.. and "64bit" means AMD64... if we just had "LINUX" > and > > > "LINUX64" hardly anyone would see a problem.. > > > > Sorry, small misunderstanding. I didn't want to omit all > architecture/ > > processor information, just leave out the LIBC6. So perhaps > > LINUX_MIPS32 or LINUX_AMD64 etc. would suffice? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Mar 29 04:52:10 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 29 Mar 2009 02:52:10 +0000 Subject: [M3devel] NetBSD2_i386 archives available Message-ID: NetBSD2_i386 min/std archives are now at http://modula3.elegosoft.com/cm3/uploaded-archives/ They have paths to /tmp/random/*.so. You will want to set $LD_LIBRARY_PATH, for example: export LD_LIBRARY_PATH=/cm3/lib or export LD_LIBRARY_PATH=/usr/local/cm3/lib This is fixed, but after I made the archives. (You'll still need to set LD_LIBRARY_PATH.) It'll be nice I think to use "$ORIGIN" on NetBSD 5.0 and wherever else it is supported, and set the paths to $ORIGIN/../lib. That way the install point can be anywhere and at least "installed"/shipped binaries can run without any environment variable. This isn't a new port, but it had been mising in recent releases. I wasn't able to bootstrap from the most recent release, didn't debug that, so did a cross build. This was actually on NetBSD 4.0.1, not "2". I switched it to use pthreads by default and the newer/smaller/more-portable *.i3 files. I did not build or test user threads, but, as with Linux/Darwin/SOL*, I left in the older Usignal.i3 etc. for their support. I did the work in Virtual PC; it was slow. Juno and formsedit startup and display remotely. I didn't have the patience for Juno to finish initializing. I don't know if I deleted all the *.tar.gz files by accident or they were lost or what, but I restored them all from the *.tar.lzma files. - Jay From hendrik at topoi.pooq.com Sun Mar 29 21:10:56 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 29 Mar 2009 15:10:56 -0400 Subject: [M3devel] small objects Message-ID: <20090329191056.GA5664@topoi.pooq.com> There are many times I want to express data which could be efficiently coded as the disjoing union of (small) integer and pointer to object. The pointer-to-object is used in the case where tho objects are big; the (small) integer for the more common case where the objects are small. High-level languages seem to pe quite paranoid about admitting thise kind of data into the fold, except maybe for Lisp systems, which have been doing this from time immemorial. (I believe CAML does this, too). These languages use it internally, and manage to (mostly) hide it from the user. The X toolkit uses this trick too -- there's a constant somewhere, and if an integer is less than this constant, it's passed to an X toolkit function as an integer; otherwise by reference. The idea there is that there's a range of addresses of storage that can never be used as parameters for the X toolkit functions (presumably because of hardware or OS limitations), and that the bit patterns that are unavailable for addresses can be used as small integers. Now the semantics of such a union, efficiently coded, are quite clear. There's a range of numbers that can be packed unamiguously into pointers, and if your integer can be so packed, you do it; otherwise you use a reference to sime kind of INTEGER object elsewhere. There are operations for packing integers and object pointers into such words, and others for unpacking them (complete with type-test). The actual physical representation can be machine- or implemetation dependent -- you could do a bit of shifting and pack integers into words with the low bit set (if pointers to objects are usually aligned in some way, the integers will stand out as being unalinged) Or you could use an uppoer bound on "small" integers, as C does. And on a machine where such packing is impossible (for whatever reason) you could simply set the upper bound of (the absolute alue of) such packable integers to be zero, so there wouldn't be any. Is there any way such a thing can be done in Modula 3? Remember -- I do want the garbage collector to be aware of such conventions and do proper tracing on the pointers? (I suspect the answer is "no". But would be a pity.) -- hendrik From mika at async.caltech.edu Sun Mar 29 21:31:19 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 12:31:19 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Sun, 29 Mar 2009 15:10:56 EDT." <20090329191056.GA5664@topoi.pooq.com> Message-ID: <200903291931.n2TJVJoR045850@camembert.async.caltech.edu> I asked Tony about this and he said that currently it will confuse the GC but that it's a minor change. I wanted it for my proposed Smalltalk-in-M3 environment, which has since morphed to a Scheme-in-M3 environment (much easier to code), and I would still like it :-) (But I have plenty of other issues in my environment also that need my attention more urgently at the moment...) Mika hendrik at topoi.pooq.com writes: >There are many times I want to express data which could be efficiently >coded as the disjoing union of (small) integer and pointer to object. >The pointer-to-object is used in the case where tho objects are big; >the (small) integer for the more common case where the objects are >small. > >High-level languages seem to pe quite paranoid about admitting thise >kind of data into the fold, except maybe for Lisp systems, which have >been doing this from time immemorial. (I believe CAML does this, too). >These languages use it internally, and manage to (mostly) hide it from >the user. > >The X toolkit uses this trick too -- there's a constant somewhere, and >if an integer is less than this constant, it's passed to an X toolkit >function as an integer; otherwise by reference. The idea there is that >there's a range of addresses of storage that can never be used as >parameters for the X toolkit functions (presumably because of hardware >or OS limitations), and that the bit patterns that are unavailable for >addresses can be used as small integers. > >Now the semantics of such a union, efficiently coded, are quite clear. >There's a range of numbers that can be packed unamiguously into >pointers, and if your integer can be so packed, you do it; >otherwise you use a reference to sime kind of INTEGER object >elsewhere. There are operations for packing integers and object >pointers into such words, and others for unpacking them (complete with >type-test). The actual physical representation can be machine- or >implemetation dependent -- you could do a bit of shifting and pack >integers into words with the low bit set (if pointers to objects are usually aligned in some way, the integers will stand out as being >unalinged) Or you could use an uppoer bound on "small" integers, as C >does. And on a machine where such packing is impossible (for whatever >reason) you could simply set the upper bound of (the absolute alue >of) such packable integers to be zero, so there wouldn't be any. > >Is there any way such a thing can be done in Modula 3? Remember -- I do >want the garbage collector to be aware of such conventions and do proper >tracing on the pointers? > >(I suspect the answer is "no". But would be a pity.) > >-- hendrik From mika at async.caltech.edu Sun Mar 29 21:33:47 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 12:33:47 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Sun, 29 Mar 2009 15:10:56 EDT." <20090329191056.GA5664@topoi.pooq.com> Message-ID: <200903291933.n2TJXlxM045919@camembert.async.caltech.edu> You probably mean something like this: http://www.async.caltech.edu/~mika/interp/ Note that this code, as it stands, probably does not work (if we are to trust what the implementor of the garbage collector has said). Mika hendrik at topoi.pooq.com writes: >There are many times I want to express data which could be efficiently >coded as the disjoing union of (small) integer and pointer to object. >The pointer-to-object is used in the case where tho objects are big; >the (small) integer for the more common case where the objects are >small. > >High-level languages seem to pe quite paranoid about admitting thise >kind of data into the fold, except maybe for Lisp systems, which have >been doing this from time immemorial. (I believe CAML does this, too). >These languages use it internally, and manage to (mostly) hide it from >the user. > >The X toolkit uses this trick too -- there's a constant somewhere, and >if an integer is less than this constant, it's passed to an X toolkit >function as an integer; otherwise by reference. The idea there is that >there's a range of addresses of storage that can never be used as >parameters for the X toolkit functions (presumably because of hardware >or OS limitations), and that the bit patterns that are unavailable for >addresses can be used as small integers. > >Now the semantics of such a union, efficiently coded, are quite clear. >There's a range of numbers that can be packed unamiguously into >pointers, and if your integer can be so packed, you do it; >otherwise you use a reference to sime kind of INTEGER object >elsewhere. There are operations for packing integers and object >pointers into such words, and others for unpacking them (complete with >type-test). The actual physical representation can be machine- or >implemetation dependent -- you could do a bit of shifting and pack >integers into words with the low bit set (if pointers to objects are usually aligned in some way, the integers will stand out as being >unalinged) Or you could use an uppoer bound on "small" integers, as C >does. And on a machine where such packing is impossible (for whatever >reason) you could simply set the upper bound of (the absolute alue >of) such packable integers to be zero, so there wouldn't be any. > >Is there any way such a thing can be done in Modula 3? Remember -- I do >want the garbage collector to be aware of such conventions and do proper >tracing on the pointers? > >(I suspect the answer is "no". But would be a pity.) > >-- hendrik From jay.krell at cornell.edu Sun Mar 29 22:19:32 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 29 Mar 2009 20:19:32 +0000 Subject: [M3devel] small objects In-Reply-To: <200903291931.n2TJVJoR045850@camembert.async.caltech.edu> References: Your message of "Sun, 29 Mar 2009 15:10:56 EDT." <20090329191056.GA5664@topoi.pooq.com> <200903291931.n2TJVJoR045850@camembert.async.caltech.edu> Message-ID: Can we say that anything under 64K is invalid? And in RTAllocator, do some gymnastics to make it so? In particular, like: if an allocation from memmap/malloc/sbrk is under 64K: if it is "small", leak it, and try again if it is "large", free it, and try again This does not guarantee forward progress in the large case. So, if it is large...? Free it, allocate something small, if it is under 64K, leak it, and try again. If it is not under 64K, free it, allocate something larger?' This is better, but can still loop forever. I guess sbrk returns always increasing addresses? If you chose 4K instead of 64K, easier/more portable, given that all existing systems have page size>=4K and NULL is invalid, so 0-4K are invalid. - Jay ---------------------------------------- > To: hendrik at topoi.pooq.com > Date: Sun, 29 Mar 2009 12:31:19 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] small objects > > I asked Tony about this and he said that currently it will confuse > the GC but that it's a minor change. > > I wanted it for my proposed Smalltalk-in-M3 environment, which has > since morphed to a Scheme-in-M3 environment (much easier to code), > and I would still like it :-) (But I have plenty of other issues > in my environment also that need my attention more urgently > at the moment...) > > Mika > > hendrik at topoi.pooq.com writes: >>There are many times I want to express data which could be efficiently >>coded as the disjoing union of (small) integer and pointer to object. >>The pointer-to-object is used in the case where tho objects are big; >>the (small) integer for the more common case where the objects are >>small. >> >>High-level languages seem to pe quite paranoid about admitting thise >>kind of data into the fold, except maybe for Lisp systems, which have >>been doing this from time immemorial. (I believe CAML does this, too). >>These languages use it internally, and manage to (mostly) hide it from >>the user. >> >>The X toolkit uses this trick too -- there's a constant somewhere, and >>if an integer is less than this constant, it's passed to an X toolkit >>function as an integer; otherwise by reference. The idea there is that >>there's a range of addresses of storage that can never be used as >>parameters for the X toolkit functions (presumably because of hardware >>or OS limitations), and that the bit patterns that are unavailable for >>addresses can be used as small integers. >> >>Now the semantics of such a union, efficiently coded, are quite clear. >>There's a range of numbers that can be packed unamiguously into >>pointers, and if your integer can be so packed, you do it; >>otherwise you use a reference to sime kind of INTEGER object >>elsewhere. There are operations for packing integers and object >>pointers into such words, and others for unpacking them (complete with >>type-test). The actual physical representation can be machine- or >>implemetation dependent -- you could do a bit of shifting and pack >>integers into words with the low bit set (if pointers to objects are > usually aligned in some way, the integers will stand out as being >>unalinged) Or you could use an uppoer bound on "small" integers, as C >>does. And on a machine where such packing is impossible (for whatever >>reason) you could simply set the upper bound of (the absolute alue >>of) such packable integers to be zero, so there wouldn't be any. >> >>Is there any way such a thing can be done in Modula 3? Remember -- I do >>want the garbage collector to be aware of such conventions and do proper >>tracing on the pointers? >> >>(I suspect the answer is "no". But would be a pity.) >> >>-- hendrik From mika at async.caltech.edu Sun Mar 29 22:23:03 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 13:23:03 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Sun, 29 Mar 2009 20:19:32 -0000." Message-ID: <200903292023.n2TKN310047704@camembert.async.caltech.edu> My code just shifts the word over by one and sets the LSB to 1. Same as in the Blue Book (that's "Smalltalk-80" by Goldberg and Robson). Mika Jay writes: > >Can we say that anything under 64K is invalid? >And in RTAllocator, do some gymnastics to make it so? >In particular, like: > if an allocation from memmap/malloc/sbrk is under 64K: > if it is "small", leak it, and try again > if it is "large", free it, and try again > This does not guarantee forward progress in the large case. > So, if it is large...? > Free it, allocate something small, if it is under 64K, leak it, and try again. > If it is not under 64K, free it, allocate something larger?' > This is better, but can still loop forever. > >I guess sbrk returns always increasing addresses? >If you chose 4K instead of 64K, easier/more portable, given that all existing systems have page size>=4K and NULL is invalid, so 0-4K are invalid. > > - Jay > > >---------------------------------------- >> To: hendrik at topoi.pooq.com >> Date: Sun, 29 Mar 2009 12:31:19 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] small objects >> >> I asked Tony about this and he said that currently it will confuse >> the GC but that it's a minor change. >> >> I wanted it for my proposed Smalltalk-in-M3 environment, which has >> since morphed to a Scheme-in-M3 environment (much easier to code), >> and I would still like it :-) (But I have plenty of other issues >> in my environment also that need my attention more urgently >> at the moment...) >> >> Mika >> >> hendrik at topoi.pooq.com writes: >>>There are many times I want to express data which could be efficiently >>>coded as the disjoing union of (small) integer and pointer to object. >>>The pointer-to-object is used in the case where tho objects are big; >>>the (small) integer for the more common case where the objects are >>>small. >>> >>>High-level languages seem to pe quite paranoid about admitting thise >>>kind of data into the fold, except maybe for Lisp systems, which have >>>been doing this from time immemorial. (I believe CAML does this, too). >>>These languages use it internally, and manage to (mostly) hide it from >>>the user. >>> >>>The X toolkit uses this trick too -- there's a constant somewhere, and >>>if an integer is less than this constant, it's passed to an X toolkit >>>function as an integer; otherwise by reference. The idea there is that >>>there's a range of addresses of storage that can never be used as >>>parameters for the X toolkit functions (presumably because of hardware >>>or OS limitations), and that the bit patterns that are unavailable for >>>addresses can be used as small integers. >>> >>>Now the semantics of such a union, efficiently coded, are quite clear. >>>There's a range of numbers that can be packed unamiguously into >>>pointers, and if your integer can be so packed, you do it; >>>otherwise you use a reference to sime kind of INTEGER object >>>elsewhere. There are operations for packing integers and object >>>pointers into such words, and others for unpacking them (complete with >>>type-test). The actual physical representation can be machine- or >>>implemetation dependent -- you could do a bit of shifting and pack >>>integers into words with the low bit set (if pointers to objects are >> usually aligned in some way, the integers will stand out as being >>>unalinged) Or you could use an uppoer bound on "small" integers, as C >>>does. And on a machine where such packing is impossible (for whatever >>>reason) you could simply set the upper bound of (the absolute alue >>>of) such packable integers to be zero, so there wouldn't be any. >>> >>>Is there any way such a thing can be done in Modula 3? Remember -- I do >>>want the garbage collector to be aware of such conventions and do proper >>>tracing on the pointers? >>> >>>(I suspect the answer is "no". But would be a pity.) >>> >>>-- hendrik From jay.krell at cornell.edu Sun Mar 29 22:25:38 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 29 Mar 2009 20:25:38 +0000 Subject: [M3devel] small objects In-Reply-To: <200903291931.n2TJVJoR045850@camembert.async.caltech.edu> References: Your message of "Sun, 29 Mar 2009 15:10:56 EDT." <20090329191056.GA5664@topoi.pooq.com> <200903291931.n2TJVJoR045850@camembert.async.caltech.edu> Message-ID: You can also depend on heap being somewhat aligned and use the lower bits as "tag" bits. Like, if you need all 30bit integers to be not heap allocated or somesuch. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu; hendrik at topoi.pooq.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] small objects > Date: Sun, 29 Mar 2009 20:19:32 +0000 > > > Can we say that anything under 64K is invalid? > And in RTAllocator, do some gymnastics to make it so? > In particular, like: > if an allocation from memmap/malloc/sbrk is under 64K: > if it is "small", leak it, and try again > if it is "large", free it, and try again > This does not guarantee forward progress in the large case. > So, if it is large...? > Free it, allocate something small, if it is under 64K, leak it, and try again. > If it is not under 64K, free it, allocate something larger?' > This is better, but can still loop forever. > > I guess sbrk returns always increasing addresses? > If you chose 4K instead of 64K, easier/more portable, given that all existing systems have page size>=4K and NULL is invalid, so 0-4K are invalid. > > - Jay > > > ---------------------------------------- >> To: hendrik at topoi.pooq.com >> Date: Sun, 29 Mar 2009 12:31:19 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] small objects >> >> I asked Tony about this and he said that currently it will confuse >> the GC but that it's a minor change. >> >> I wanted it for my proposed Smalltalk-in-M3 environment, which has >> since morphed to a Scheme-in-M3 environment (much easier to code), >> and I would still like it :-) (But I have plenty of other issues >> in my environment also that need my attention more urgently >> at the moment...) >> >> Mika >> >> hendrik at topoi.pooq.com writes: >>>There are many times I want to express data which could be efficiently >>>coded as the disjoing union of (small) integer and pointer to object. >>>The pointer-to-object is used in the case where tho objects are big; >>>the (small) integer for the more common case where the objects are >>>small. >>> >>>High-level languages seem to pe quite paranoid about admitting thise >>>kind of data into the fold, except maybe for Lisp systems, which have >>>been doing this from time immemorial. (I believe CAML does this, too). >>>These languages use it internally, and manage to (mostly) hide it from >>>the user. >>> >>>The X toolkit uses this trick too -- there's a constant somewhere, and >>>if an integer is less than this constant, it's passed to an X toolkit >>>function as an integer; otherwise by reference. The idea there is that >>>there's a range of addresses of storage that can never be used as >>>parameters for the X toolkit functions (presumably because of hardware >>>or OS limitations), and that the bit patterns that are unavailable for >>>addresses can be used as small integers. >>> >>>Now the semantics of such a union, efficiently coded, are quite clear. >>>There's a range of numbers that can be packed unamiguously into >>>pointers, and if your integer can be so packed, you do it; >>>otherwise you use a reference to sime kind of INTEGER object >>>elsewhere. There are operations for packing integers and object >>>pointers into such words, and others for unpacking them (complete with >>>type-test). The actual physical representation can be machine- or >>>implemetation dependent -- you could do a bit of shifting and pack >>>integers into words with the low bit set (if pointers to objects are >> usually aligned in some way, the integers will stand out as being >>>unalinged) Or you could use an uppoer bound on "small" integers, as C >>>does. And on a machine where such packing is impossible (for whatever >>>reason) you could simply set the upper bound of (the absolute alue >>>of) such packable integers to be zero, so there wouldn't be any. >>> >>>Is there any way such a thing can be done in Modula 3? Remember -- I do >>>want the garbage collector to be aware of such conventions and do proper >>>tracing on the pointers? >>> >>>(I suspect the answer is "no". But would be a pity.) >>> >>>-- hendrik From hosking at cs.purdue.edu Mon Mar 30 01:34:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Mar 2009 10:34:43 +1100 Subject: [M3devel] small objects In-Reply-To: <20090329191056.GA5664@topoi.pooq.com> References: <20090329191056.GA5664@topoi.pooq.com> Message-ID: <0885F24C-4D78-481E-8B2B-03353AAAEC2C@cs.purdue.edu> If we could accurately type values in the stack/registers at run time then this would not be a problem. Unfortunately, the compiler does not do this, so it is possible for a derived pointer (reference + offset) to be formed in stack/registers that the garbage collector won't be able to distinguish between one of your tagged values and some derived pointer into the middle of an object. If we could assume that the heap never allocates from some known set of addresses then we could safely distinguish the tagged values. On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: > There are many times I want to express data which could be efficiently > coded as the disjoing union of (small) integer and pointer to object. > The pointer-to-object is used in the case where tho objects are big; > the (small) integer for the more common case where the objects are > small. > > High-level languages seem to pe quite paranoid about admitting thise > kind of data into the fold, except maybe for Lisp systems, which have > been doing this from time immemorial. (I believe CAML does this, > too). > These languages use it internally, and manage to (mostly) hide it from > the user. > > The X toolkit uses this trick too -- there's a constant somewhere, and > if an integer is less than this constant, it's passed to an X toolkit > function as an integer; otherwise by reference. The idea there is > that > there's a range of addresses of storage that can never be used as > parameters for the X toolkit functions (presumably because of hardware > or OS limitations), and that the bit patterns that are unavailable for > addresses can be used as small integers. > > Now the semantics of such a union, efficiently coded, are quite clear. > There's a range of numbers that can be packed unamiguously into > pointers, and if your integer can be so packed, you do it; > otherwise you use a reference to sime kind of INTEGER object > elsewhere. There are operations for packing integers and object > pointers into such words, and others for unpacking them (complete with > type-test). The actual physical representation can be machine- or > implemetation dependent -- you could do a bit of shifting and pack > integers into words with the low bit set (if pointers to objects are > usually aligned in some way, the integers will stand out as being > unalinged) Or you could use an uppoer bound on "small" integers, as C > does. And on a machine where such packing is impossible (for whatever > reason) you could simply set the upper bound of (the absolute alue > of) such packable integers to be zero, so there wouldn't be any. > > Is there any way such a thing can be done in Modula 3? Remember -- > I do > want the garbage collector to be aware of such conventions and do > proper > tracing on the pointers? > > (I suspect the answer is "no". But would be a pity.) > > -- hendrik From hosking at cs.purdue.edu Mon Mar 30 01:27:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Mar 2009 10:27:24 +1100 Subject: [M3devel] small objects In-Reply-To: <20090329191056.GA5664@topoi.pooq.com> References: <20090329191056.GA5664@topoi.pooq.com> Message-ID: <332103DB-A166-4516-809C-529BA0317729@cs.purdue.edu> If we could accurately type values in the stack/registers at run time then this would not be a problem. Unfortunately, the compiler does not do this, so it is possible for a derived pointer (reference + offset) to be formed in stack/registers that the garbage collector won't be able to distinguish between one of your tagged values and some derived pointer into the middle of an object. If we could assume that the heap never allocates from some known set of addresses then we could safely distinguish the tagged values. On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: > There are many times I want to express data which could be efficiently > coded as the disjoing union of (small) integer and pointer to object. > The pointer-to-object is used in the case where tho objects are big; > the (small) integer for the more common case where the objects are > small. > > High-level languages seem to pe quite paranoid about admitting thise > kind of data into the fold, except maybe for Lisp systems, which have > been doing this from time immemorial. (I believe CAML does this, > too). > These languages use it internally, and manage to (mostly) hide it from > the user. > > The X toolkit uses this trick too -- there's a constant somewhere, and > if an integer is less than this constant, it's passed to an X toolkit > function as an integer; otherwise by reference. The idea there is > that > there's a range of addresses of storage that can never be used as > parameters for the X toolkit functions (presumably because of hardware > or OS limitations), and that the bit patterns that are unavailable for > addresses can be used as small integers. > > Now the semantics of such a union, efficiently coded, are quite clear. > There's a range of numbers that can be packed unamiguously into > pointers, and if your integer can be so packed, you do it; > otherwise you use a reference to sime kind of INTEGER object > elsewhere. There are operations for packing integers and object > pointers into such words, and others for unpacking them (complete with > type-test). The actual physical representation can be machine- or > implemetation dependent -- you could do a bit of shifting and pack > integers into words with the low bit set (if pointers to objects are > usually aligned in some way, the integers will stand out as being > unalinged) Or you could use an uppoer bound on "small" integers, as C > does. And on a machine where such packing is impossible (for whatever > reason) you could simply set the upper bound of (the absolute alue > of) such packable integers to be zero, so there wouldn't be any. > > Is there any way such a thing can be done in Modula 3? Remember -- > I do > want the garbage collector to be aware of such conventions and do > proper > tracing on the pointers? > > (I suspect the answer is "no". But would be a pity.) > > -- hendrik From hosking at cs.purdue.edu Mon Mar 30 01:13:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Mar 2009 10:13:43 +1100 Subject: [M3devel] small objects In-Reply-To: References: Your message of "Sun, 29 Mar 2009 15:10:56 EDT." <20090329191056.GA5664@topoi.pooq.com> <200903291931.n2TJVJoR045850@camembert.async.caltech.edu> Message-ID: <3E9AE7FF-BEFC-4E0E-98B5-4F1768F87764@cs.purdue.edu> No good if the tag bits are the same as unaligned pointers from the stack/registers -- we'd end up conservatively pinning pages that just happened to have addresses that coincide with the tagged values. On 30 Mar 2009, at 07:25, Jay wrote: > > You can also depend on heap being somewhat aligned and use the lower > bits as "tag" bits. Like, if you need all 30bit integers to be not > heap allocated or somesuch. > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: mika at async.caltech.edu; hendrik at topoi.pooq.com >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] small objects >> Date: Sun, 29 Mar 2009 20:19:32 +0000 >> >> >> Can we say that anything under 64K is invalid? >> And in RTAllocator, do some gymnastics to make it so? >> In particular, like: >> if an allocation from memmap/malloc/sbrk is under 64K: >> if it is "small", leak it, and try again >> if it is "large", free it, and try again >> This does not guarantee forward progress in the large case. >> So, if it is large...? >> Free it, allocate something small, if it is under 64K, leak it, and >> try again. >> If it is not under 64K, free it, allocate something larger?' >> This is better, but can still loop forever. >> >> I guess sbrk returns always increasing addresses? >> If you chose 4K instead of 64K, easier/more portable, given that >> all existing systems have page size>=4K and NULL is invalid, so >> 0-4K are invalid. >> >> - Jay >> >> >> ---------------------------------------- >>> To: hendrik at topoi.pooq.com >>> Date: Sun, 29 Mar 2009 12:31:19 -0700 >>> From: mika at async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] small objects >>> >>> I asked Tony about this and he said that currently it will confuse >>> the GC but that it's a minor change. >>> >>> I wanted it for my proposed Smalltalk-in-M3 environment, which has >>> since morphed to a Scheme-in-M3 environment (much easier to code), >>> and I would still like it :-) (But I have plenty of other issues >>> in my environment also that need my attention more urgently >>> at the moment...) >>> >>> Mika >>> >>> hendrik at topoi.pooq.com writes: >>>> There are many times I want to express data which could be >>>> efficiently >>>> coded as the disjoing union of (small) integer and pointer to >>>> object. >>>> The pointer-to-object is used in the case where tho objects are >>>> big; >>>> the (small) integer for the more common case where the objects are >>>> small. >>>> >>>> High-level languages seem to pe quite paranoid about admitting >>>> thise >>>> kind of data into the fold, except maybe for Lisp systems, which >>>> have >>>> been doing this from time immemorial. (I believe CAML does this, >>>> too). >>>> These languages use it internally, and manage to (mostly) hide it >>>> from >>>> the user. >>>> >>>> The X toolkit uses this trick too -- there's a constant >>>> somewhere, and >>>> if an integer is less than this constant, it's passed to an X >>>> toolkit >>>> function as an integer; otherwise by reference. The idea there is >>>> that >>>> there's a range of addresses of storage that can never be used as >>>> parameters for the X toolkit functions (presumably because of >>>> hardware >>>> or OS limitations), and that the bit patterns that are >>>> unavailable for >>>> addresses can be used as small integers. >>>> >>>> Now the semantics of such a union, efficiently coded, are quite >>>> clear. >>>> There's a range of numbers that can be packed unamiguously into >>>> pointers, and if your integer can be so packed, you do it; >>>> otherwise you use a reference to sime kind of INTEGER object >>>> elsewhere. There are operations for packing integers and object >>>> pointers into such words, and others for unpacking them (complete >>>> with >>>> type-test). The actual physical representation can be machine- or >>>> implemetation dependent -- you could do a bit of shifting and pack >>>> integers into words with the low bit set (if pointers to objects >>>> are >>> usually aligned in some way, the integers will stand out as being >>>> unalinged) Or you could use an uppoer bound on "small" integers, >>>> as C >>>> does. And on a machine where such packing is impossible (for >>>> whatever >>>> reason) you could simply set the upper bound of (the absolute alue >>>> of) such packable integers to be zero, so there wouldn't be any. >>>> >>>> Is there any way such a thing can be done in Modula 3? Remember >>>> -- I do >>>> want the garbage collector to be aware of such conventions and do >>>> proper >>>> tracing on the pointers? >>>> >>>> (I suspect the answer is "no". But would be a pity.) >>>> >>>> -- hendrik From mika at async.caltech.edu Mon Mar 30 01:49:14 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 16:49:14 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 30 Mar 2009 10:34:43 +1100." <0885F24C-4D78-481E-8B2B-03353AAAEC2C@cs.purdue.edu> Message-ID: <200903292349.n2TNnEPv054525@camembert.async.caltech.edu> Tony, Doesn't this already happen with INTEGER, REAL, LONGREAL, etc., objects? Mika Tony Hosking writes: >If we could accurately type values in the stack/registers at run time >then this would not be a problem. Unfortunately, the compiler does >not do this, so it is possible for a derived pointer (reference + >offset) to be formed in stack/registers that the garbage collector >won't be able to distinguish between one of your tagged values and >some derived pointer into the middle of an object. If we could assume >that the heap never allocates from some known set of addresses then we >could safely distinguish the tagged values. > >On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: > >> There are many times I want to express data which could be efficiently >> coded as the disjoing union of (small) integer and pointer to object. >> The pointer-to-object is used in the case where tho objects are big; >> the (small) integer for the more common case where the objects are >> small. >> >> High-level languages seem to pe quite paranoid about admitting thise >> kind of data into the fold, except maybe for Lisp systems, which have >> been doing this from time immemorial. (I believe CAML does this, >> too). >> These languages use it internally, and manage to (mostly) hide it from >> the user. >> >> The X toolkit uses this trick too -- there's a constant somewhere, and >> if an integer is less than this constant, it's passed to an X toolkit >> function as an integer; otherwise by reference. The idea there is >> that >> there's a range of addresses of storage that can never be used as >> parameters for the X toolkit functions (presumably because of hardware >> or OS limitations), and that the bit patterns that are unavailable for >> addresses can be used as small integers. >> >> Now the semantics of such a union, efficiently coded, are quite clear. >> There's a range of numbers that can be packed unamiguously into >> pointers, and if your integer can be so packed, you do it; >> otherwise you use a reference to sime kind of INTEGER object >> elsewhere. There are operations for packing integers and object >> pointers into such words, and others for unpacking them (complete with >> type-test). The actual physical representation can be machine- or >> implemetation dependent -- you could do a bit of shifting and pack >> integers into words with the low bit set (if pointers to objects are >> usually aligned in some way, the integers will stand out as being >> unalinged) Or you could use an uppoer bound on "small" integers, as C >> does. And on a machine where such packing is impossible (for whatever >> reason) you could simply set the upper bound of (the absolute alue >> of) such packable integers to be zero, so there wouldn't be any. >> >> Is there any way such a thing can be done in Modula 3? Remember -- >> I do >> want the garbage collector to be aware of such conventions and do >> proper >> tracing on the pointers? >> >> (I suspect the answer is "no". But would be a pity.) >> >> -- hendrik From hosking at cs.purdue.edu Mon Mar 30 03:12:12 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Mar 2009 12:12:12 +1100 Subject: [M3devel] small objects In-Reply-To: <200903292349.n2TNnEPv054525@camembert.async.caltech.edu> References: <200903292349.n2TNnEPv054525@camembert.async.caltech.edu> Message-ID: Sorry, yes, I am not awake yet this morning. Need more coffeee. Of course this occurs even for all untagged values. The main problem is that it would be dangerous generally to allow reference fields to contain tagged values, since then even safe code could try to dereference what would amount to actually being a tagged value non-reference. What we really need is a new type "tagged reference" distinct from normal references with associated API to extract the reference/value it holds. The compiler would need to generate heap maps that include these for processing by the collector, just as it does for ordinary references. On 30 Mar 2009, at 10:49, Mika Nystrom wrote: > Tony, > > Doesn't this already happen with INTEGER, REAL, LONGREAL, etc., > objects? > > Mika > > Tony Hosking writes: >> If we could accurately type values in the stack/registers at run time >> then this would not be a problem. Unfortunately, the compiler does >> not do this, so it is possible for a derived pointer (reference + >> offset) to be formed in stack/registers that the garbage collector >> won't be able to distinguish between one of your tagged values and >> some derived pointer into the middle of an object. If we could >> assume >> that the heap never allocates from some known set of addresses then >> we >> could safely distinguish the tagged values. >> >> On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: >> >>> There are many times I want to express data which could be >>> efficiently >>> coded as the disjoing union of (small) integer and pointer to >>> object. >>> The pointer-to-object is used in the case where tho objects are big; >>> the (small) integer for the more common case where the objects are >>> small. >>> >>> High-level languages seem to pe quite paranoid about admitting thise >>> kind of data into the fold, except maybe for Lisp systems, which >>> have >>> been doing this from time immemorial. (I believe CAML does this, >>> too). >>> These languages use it internally, and manage to (mostly) hide it >>> from >>> the user. >>> >>> The X toolkit uses this trick too -- there's a constant somewhere, >>> and >>> if an integer is less than this constant, it's passed to an X >>> toolkit >>> function as an integer; otherwise by reference. The idea there is >>> that >>> there's a range of addresses of storage that can never be used as >>> parameters for the X toolkit functions (presumably because of >>> hardware >>> or OS limitations), and that the bit patterns that are unavailable >>> for >>> addresses can be used as small integers. >>> >>> Now the semantics of such a union, efficiently coded, are quite >>> clear. >>> There's a range of numbers that can be packed unamiguously into >>> pointers, and if your integer can be so packed, you do it; >>> otherwise you use a reference to sime kind of INTEGER object >>> elsewhere. There are operations for packing integers and object >>> pointers into such words, and others for unpacking them (complete >>> with >>> type-test). The actual physical representation can be machine- or >>> implemetation dependent -- you could do a bit of shifting and pack >>> integers into words with the low bit set (if pointers to objects are >>> usually aligned in some way, the integers will stand out as being >>> unalinged) Or you could use an uppoer bound on "small" integers, >>> as C >>> does. And on a machine where such packing is impossible (for >>> whatever >>> reason) you could simply set the upper bound of (the absolute alue >>> of) such packable integers to be zero, so there wouldn't be any. >>> >>> Is there any way such a thing can be done in Modula 3? Remember -- >>> I do >>> want the garbage collector to be aware of such conventions and do >>> proper >>> tracing on the pointers? >>> >>> (I suspect the answer is "no". But would be a pity.) >>> >>> -- hendrik From mika at async.caltech.edu Mon Mar 30 03:48:56 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 18:48:56 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 30 Mar 2009 12:12:12 +1100." Message-ID: <200903300148.n2U1mu1d058648@camembert.async.caltech.edu> Hmmmmm... in my UNSAFE INTERFACE I declare my special type as REFANY (see the URL I sent a few messages ago). Since you can't deref REFANY, I'm thinking that... it's mainly a problem with TYPECASE, TYPECODE, and ISTYPE...? (In safe code, that is.) Also the GC would have to know that refs that are # 0 (mod 4) aren't real references and not try to follow those. As long as they are on the stack or in registers there's not much you can do... I don't think this is all that difficult. My example code has a very simple API of the kind you describe. See SmallInteger.[im]3... Mika Tony Hosking writes: >Sorry, yes, I am not awake yet this morning. Need more coffeee. Of >course this occurs even for all untagged values. > >The main problem is that it would be dangerous generally to allow >reference fields to contain tagged values, since then even safe code >could try to dereference what would amount to actually being a tagged >value non-reference. What we really need is a new type "tagged >reference" distinct from normal references with associated API to >extract the reference/value it holds. The compiler would need to >generate heap maps that include these for processing by the collector, >just as it does for ordinary references. > >On 30 Mar 2009, at 10:49, Mika Nystrom wrote: > >> Tony, >> >> Doesn't this already happen with INTEGER, REAL, LONGREAL, etc., >> objects? >> >> Mika >> >> Tony Hosking writes: >>> If we could accurately type values in the stack/registers at run time >>> then this would not be a problem. Unfortunately, the compiler does >>> not do this, so it is possible for a derived pointer (reference + >>> offset) to be formed in stack/registers that the garbage collector >>> won't be able to distinguish between one of your tagged values and >>> some derived pointer into the middle of an object. If we could >>> assume >>> that the heap never allocates from some known set of addresses then >>> we >>> could safely distinguish the tagged values. >>> >>> On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: >>> >>>> There are many times I want to express data which could be >>>> efficiently >>>> coded as the disjoing union of (small) integer and pointer to >>>> object. >>>> The pointer-to-object is used in the case where tho objects are big; >>>> the (small) integer for the more common case where the objects are >>>> small. >>>> >>>> High-level languages seem to pe quite paranoid about admitting thise >>>> kind of data into the fold, except maybe for Lisp systems, which >>>> have >>>> been doing this from time immemorial. (I believe CAML does this, >>>> too). >>>> These languages use it internally, and manage to (mostly) hide it >>>> from >>>> the user. >>>> >>>> The X toolkit uses this trick too -- there's a constant somewhere, >>>> and >>>> if an integer is less than this constant, it's passed to an X >>>> toolkit >>>> function as an integer; otherwise by reference. The idea there is >>>> that >>>> there's a range of addresses of storage that can never be used as >>>> parameters for the X toolkit functions (presumably because of >>>> hardware >>>> or OS limitations), and that the bit patterns that are unavailable >>>> for >>>> addresses can be used as small integers. >>>> >>>> Now the semantics of such a union, efficiently coded, are quite >>>> clear. >>>> There's a range of numbers that can be packed unamiguously into >>>> pointers, and if your integer can be so packed, you do it; >>>> otherwise you use a reference to sime kind of INTEGER object >>>> elsewhere. There are operations for packing integers and object >>>> pointers into such words, and others for unpacking them (complete >>>> with >>>> type-test). The actual physical representation can be machine- or >>>> implemetation dependent -- you could do a bit of shifting and pack >>>> integers into words with the low bit set (if pointers to objects are >>>> usually aligned in some way, the integers will stand out as being >>>> unalinged) Or you could use an uppoer bound on "small" integers, >>>> as C >>>> does. And on a machine where such packing is impossible (for >>>> whatever >>>> reason) you could simply set the upper bound of (the absolute alue >>>> of) such packable integers to be zero, so there wouldn't be any. >>>> >>>> Is there any way such a thing can be done in Modula 3? Remember -- >>>> I do >>>> want the garbage collector to be aware of such conventions and do >>>> proper >>>> tracing on the pointers? >>>> >>>> (I suspect the answer is "no". But would be a pity.) >>>> >>>> -- hendrik > From mika at async.caltech.edu Mon Mar 30 04:06:01 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 19:06:01 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Sun, 29 Mar 2009 18:48:56 PDT." <200903300148.n2U1mu1d058648@camembert.async.caltech.edu> Message-ID: <200903300206.n2U261i4059318@camembert.async.caltech.edu> Mika Nystrom writes: >Also the GC would have to know that refs <> that are # 0 (mod 4) aren't >real references and not try to follow those. Insert, in place of <> ... that it encounters on the heap and ... From hosking at cs.purdue.edu Mon Mar 30 04:33:37 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Mar 2009 13:33:37 +1100 Subject: [M3devel] small objects In-Reply-To: <200903300148.n2U1mu1d058648@camembert.async.caltech.edu> References: <200903300148.n2U1mu1d058648@camembert.async.caltech.edu> Message-ID: Yes, I've just been thinking about this and trying to come up with a proposal, somewhat along the lines you describe. My real concern is that you don't want any of the reference operations (including down- casts) to apply to the tagged value type. But you do want the collector to be aware of it. We'd need a new builtin type like TAGGED or something and operations for extracting the values. A slightly wacky alternative might allow NULL to have values other than NIL. Doing this would require smartening up the compiler and run- time to allow for non-NIL NULL values. This would let a REFANY hold any number of different NULL values. Unfortunately, the representation of NIL as 0 and other NULL values using a tag bit doesn't make for an easy catch-all test for NULL. On 30 Mar 2009, at 12:48, Mika Nystrom wrote: > Hmmmmm... in my UNSAFE INTERFACE I declare my special type as > REFANY (see the URL I sent a few messages ago). > > Since you can't deref REFANY, I'm thinking that... it's mainly a > problem with TYPECASE, TYPECODE, and ISTYPE...? (In safe code, > that is.) > > Also the GC would have to know that refs that are # 0 (mod 4) aren't > real references and not try to follow those. As long as they are > on the stack or in registers there's not much you can do... > > I don't think this is all that difficult. My example code has a very > simple API of the kind you describe. See SmallInteger.[im]3... > > Mika > > Tony Hosking writes: >> Sorry, yes, I am not awake yet this morning. Need more coffeee. Of >> course this occurs even for all untagged values. >> >> The main problem is that it would be dangerous generally to allow >> reference fields to contain tagged values, since then even safe code >> could try to dereference what would amount to actually being a tagged >> value non-reference. What we really need is a new type "tagged >> reference" distinct from normal references with associated API to >> extract the reference/value it holds. The compiler would need to >> generate heap maps that include these for processing by the >> collector, >> just as it does for ordinary references. >> >> On 30 Mar 2009, at 10:49, Mika Nystrom wrote: >> >>> Tony, >>> >>> Doesn't this already happen with INTEGER, REAL, LONGREAL, etc., >>> objects? >>> >>> Mika >>> >>> Tony Hosking writes: >>>> If we could accurately type values in the stack/registers at run >>>> time >>>> then this would not be a problem. Unfortunately, the compiler does >>>> not do this, so it is possible for a derived pointer (reference + >>>> offset) to be formed in stack/registers that the garbage collector >>>> won't be able to distinguish between one of your tagged values and >>>> some derived pointer into the middle of an object. If we could >>>> assume >>>> that the heap never allocates from some known set of addresses then >>>> we >>>> could safely distinguish the tagged values. >>>> >>>> On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: >>>> >>>>> There are many times I want to express data which could be >>>>> efficiently >>>>> coded as the disjoing union of (small) integer and pointer to >>>>> object. >>>>> The pointer-to-object is used in the case where tho objects are >>>>> big; >>>>> the (small) integer for the more common case where the objects are >>>>> small. >>>>> >>>>> High-level languages seem to pe quite paranoid about admitting >>>>> thise >>>>> kind of data into the fold, except maybe for Lisp systems, which >>>>> have >>>>> been doing this from time immemorial. (I believe CAML does this, >>>>> too). >>>>> These languages use it internally, and manage to (mostly) hide it >>>>> from >>>>> the user. >>>>> >>>>> The X toolkit uses this trick too -- there's a constant somewhere, >>>>> and >>>>> if an integer is less than this constant, it's passed to an X >>>>> toolkit >>>>> function as an integer; otherwise by reference. The idea there is >>>>> that >>>>> there's a range of addresses of storage that can never be used as >>>>> parameters for the X toolkit functions (presumably because of >>>>> hardware >>>>> or OS limitations), and that the bit patterns that are unavailable >>>>> for >>>>> addresses can be used as small integers. >>>>> >>>>> Now the semantics of such a union, efficiently coded, are quite >>>>> clear. >>>>> There's a range of numbers that can be packed unamiguously into >>>>> pointers, and if your integer can be so packed, you do it; >>>>> otherwise you use a reference to sime kind of INTEGER object >>>>> elsewhere. There are operations for packing integers and object >>>>> pointers into such words, and others for unpacking them (complete >>>>> with >>>>> type-test). The actual physical representation can be machine- or >>>>> implemetation dependent -- you could do a bit of shifting and pack >>>>> integers into words with the low bit set (if pointers to objects >>>>> are >>>>> usually aligned in some way, the integers will stand out as being >>>>> unalinged) Or you could use an uppoer bound on "small" integers, >>>>> as C >>>>> does. And on a machine where such packing is impossible (for >>>>> whatever >>>>> reason) you could simply set the upper bound of (the absolute alue >>>>> of) such packable integers to be zero, so there wouldn't be any. >>>>> >>>>> Is there any way such a thing can be done in Modula 3? Remember >>>>> -- >>>>> I do >>>>> want the garbage collector to be aware of such conventions and do >>>>> proper >>>>> tracing on the pointers? >>>>> >>>>> (I suspect the answer is "no". But would be a pity.) >>>>> >>>>> -- hendrik >> From martinbishop at bellsouth.net Mon Mar 30 04:44:41 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Sun, 29 Mar 2009 21:44:41 -0500 Subject: [M3devel] small objects In-Reply-To: <200903300206.n2U261i4059318@camembert.async.caltech.edu> References: <200903300206.n2U261i4059318@camembert.async.caltech.edu> Message-ID: <49D03219.9000209@bellsouth.net> Insert what? Mika Nystrom wrote: > Mika Nystrom writes: >> Also the GC would have to know that refs <> that are # 0 (mod 4) aren't >> real references and not try to follow those. > > Insert, in place of <> > > ... that it encounters on the heap and ... > From mika at async.caltech.edu Mon Mar 30 05:33:11 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 29 Mar 2009 20:33:11 -0700 Subject: [M3devel] small objects In-Reply-To: Your message of "Mon, 30 Mar 2009 13:33:37 +1100." Message-ID: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> Ah you are thinking of doing it properly. I was thinking.. "hack". Make TYPECASE, TYPECODE, ISTYPE, and NARROW abort if a REFANY holds a TaggedThing.T Make TaggedThing.IsT test if it is a TaggedThing.T TaggedThing.ToInt TaggedThing.T -> [-Min .. Max] TaggedThing.FromInt [-Min .. Max] -> TaggedThing.T REVEAL only TaggedThing.T <: REFANY I think that accomplishes everything. No? In a non-UNSAFE environment, you can't dereference it or (successfully) cast it to anything unless you have a revelation of more than REFANY, anyhow. If I understand your idea correctly, I think it really only involves adding an ISTYPE(x,TAGGED) case. There's no TYPECODE and there might be some extra complication in adding it to TYPECASE since it's not a REF... Since you might as well handle ISTYPE(x,TAGGED) with TaggedThing.IsT, do you really need anything more than I propose? (I.e., no changes to the language, just a new library interface.) Actually maybe I do mean for it to be = REFANY, not <:. Then you can't NARROW it to anything other than REFANY anyhow. ISTYPE needn't actually abort, it could just return FALSE for all cases except REFANY. Leaves only Pickles, ... or am I missing something? Mika Tony Hosking writes: >Yes, I've just been thinking about this and trying to come up with a >proposal, somewhat along the lines you describe. My real concern is >that you don't want any of the reference operations (including down- >casts) to apply to the tagged value type. But you do want the >collector to be aware of it. We'd need a new builtin type like TAGGED >or something and operations for extracting the values. > >A slightly wacky alternative might allow NULL to have values other >than NIL. Doing this would require smartening up the compiler and run- >time to allow for non-NIL NULL values. This would let a REFANY hold >any number of different NULL values. Unfortunately, the >representation of NIL as 0 and other NULL values using a tag bit >doesn't make for an easy catch-all test for NULL. > >On 30 Mar 2009, at 12:48, Mika Nystrom wrote: > >> Hmmmmm... in my UNSAFE INTERFACE I declare my special type as >> REFANY (see the URL I sent a few messages ago). >> >> Since you can't deref REFANY, I'm thinking that... it's mainly a >> problem with TYPECASE, TYPECODE, and ISTYPE...? (In safe code, >> that is.) >> >> Also the GC would have to know that refs that are # 0 (mod 4) aren't >> real references and not try to follow those. As long as they are >> on the stack or in registers there's not much you can do... >> >> I don't think this is all that difficult. My example code has a very >> simple API of the kind you describe. See SmallInteger.[im]3... >> >> Mika >> >> Tony Hosking writes: >>> Sorry, yes, I am not awake yet this morning. Need more coffeee. Of >>> course this occurs even for all untagged values. >>> >>> The main problem is that it would be dangerous generally to allow >>> reference fields to contain tagged values, since then even safe code >>> could try to dereference what would amount to actually being a tagged >>> value non-reference. What we really need is a new type "tagged >>> reference" distinct from normal references with associated API to >>> extract the reference/value it holds. The compiler would need to >>> generate heap maps that include these for processing by the >>> collector, >>> just as it does for ordinary references. >>> >>> On 30 Mar 2009, at 10:49, Mika Nystrom wrote: >>> >>>> Tony, >>>> >>>> Doesn't this already happen with INTEGER, REAL, LONGREAL, etc., >>>> objects? >>>> >>>> Mika >>>> >>>> Tony Hosking writes: >>>>> If we could accurately type values in the stack/registers at run >>>>> time >>>>> then this would not be a problem. Unfortunately, the compiler does >>>>> not do this, so it is possible for a derived pointer (reference + >>>>> offset) to be formed in stack/registers that the garbage collector >>>>> won't be able to distinguish between one of your tagged values and >>>>> some derived pointer into the middle of an object. If we could >>>>> assume >>>>> that the heap never allocates from some known set of addresses then >>>>> we >>>>> could safely distinguish the tagged values. >>>>> >>>>> On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: >>>>> >>>>>> There are many times I want to express data which could be >>>>>> efficiently >>>>>> coded as the disjoing union of (small) integer and pointer to >>>>>> object. >>>>>> The pointer-to-object is used in the case where tho objects are >>>>>> big; >>>>>> the (small) integer for the more common case where the objects are >>>>>> small. >>>>>> >>>>>> High-level languages seem to pe quite paranoid about admitting >>>>>> thise >>>>>> kind of data into the fold, except maybe for Lisp systems, which >>>>>> have >>>>>> been doing this from time immemorial. (I believe CAML does this, >>>>>> too). >>>>>> These languages use it internally, and manage to (mostly) hide it >>>>>> from >>>>>> the user. >>>>>> >>>>>> The X toolkit uses this trick too -- there's a constant somewhere, >>>>>> and >>>>>> if an integer is less than this constant, it's passed to an X >>>>>> toolkit >>>>>> function as an integer; otherwise by reference. The idea there is >>>>>> that >>>>>> there's a range of addresses of storage that can never be used as >>>>>> parameters for the X toolkit functions (presumably because of >>>>>> hardware >>>>>> or OS limitations), and that the bit patterns that are unavailable >>>>>> for >>>>>> addresses can be used as small integers. >>>>>> >>>>>> Now the semantics of such a union, efficiently coded, are quite >>>>>> clear. >>>>>> There's a range of numbers that can be packed unamiguously into >>>>>> pointers, and if your integer can be so packed, you do it; >>>>>> otherwise you use a reference to sime kind of INTEGER object >>>>>> elsewhere. There are operations for packing integers and object >>>>>> pointers into such words, and others for unpacking them (complete >>>>>> with >>>>>> type-test). The actual physical representation can be machine- or >>>>>> implemetation dependent -- you could do a bit of shifting and pack >>>>>> integers into words with the low bit set (if pointers to objects >>>>>> are >>>>>> usually aligned in some way, the integers will stand out as being >>>>>> unalinged) Or you could use an uppoer bound on "small" integers, >>>>>> as C >>>>>> does. And on a machine where such packing is impossible (for >>>>>> whatever >>>>>> reason) you could simply set the upper bound of (the absolute alue >>>>>> of) such packable integers to be zero, so there wouldn't be any. >>>>>> >>>>>> Is there any way such a thing can be done in Modula 3? Remember >>>>>> -- >>>>>> I do >>>>>> want the garbage collector to be aware of such conventions and do >>>>>> proper >>>>>> tracing on the pointers? >>>>>> >>>>>> (I suspect the answer is "no". But would be a pity.) >>>>>> >>>>>> -- hendrik >>> > From hosking at cs.purdue.edu Mon Mar 30 07:47:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Mar 2009 16:47:57 +1100 Subject: [M3devel] small objects In-Reply-To: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> References: <200903300333.n2U3XBME062502@camembert.async.caltech.edu> Message-ID: It is a much more pervasive hack than I would be comfortable with since it touches on the compiler (for all the type operations) as well as the run-time system in ways that are pretty gross. I would much rather have a new TAGGED builtin. ISTYPE would not work on it since that only works on references. The only thing you need is a way to extract the value -- we could overload VAL(x, T) where x can be a TAGGED and T can be REFANY or INTEGER. On 30 Mar 2009, at 14:33, Mika Nystrom wrote: > Ah you are thinking of doing it properly. > > I was thinking.. "hack". Make TYPECASE, TYPECODE, ISTYPE, and NARROW > abort if a REFANY holds a TaggedThing.T > > Make TaggedThing.IsT test if it is a TaggedThing.T > > TaggedThing.ToInt TaggedThing.T -> [-Min .. Max] > > TaggedThing.FromInt [-Min .. Max] -> TaggedThing.T > > REVEAL only TaggedThing.T <: REFANY > > I think that accomplishes everything. No? In a non-UNSAFE > environment, you can't dereference it or (successfully) cast it to > anything unless you have a revelation of more than REFANY, anyhow. > > If I understand your idea correctly, I think it really only involves > adding an ISTYPE(x,TAGGED) case. There's no TYPECODE and there might > be some extra complication in adding it to TYPECASE since it's not > a REF... > > Since you might as well handle ISTYPE(x,TAGGED) with TaggedThing.IsT, > do you really need anything more than I propose? (I.e., no changes > to the language, just a new library interface.) > > Actually maybe I do mean for it to be = REFANY, not <:. Then you > can't NARROW it to anything other than REFANY anyhow. > > ISTYPE needn't actually abort, it could just return FALSE for > all cases except REFANY. > > Leaves only Pickles, ... or am I missing something? > > Mika > > Tony Hosking writes: >> Yes, I've just been thinking about this and trying to come up with a >> proposal, somewhat along the lines you describe. My real concern is >> that you don't want any of the reference operations (including down- >> casts) to apply to the tagged value type. But you do want the >> collector to be aware of it. We'd need a new builtin type like >> TAGGED >> or something and operations for extracting the values. >> >> A slightly wacky alternative might allow NULL to have values other >> than NIL. Doing this would require smartening up the compiler and >> run- >> time to allow for non-NIL NULL values. This would let a REFANY hold >> any number of different NULL values. Unfortunately, the >> representation of NIL as 0 and other NULL values using a tag bit >> doesn't make for an easy catch-all test for NULL. >> >> On 30 Mar 2009, at 12:48, Mika Nystrom wrote: >> >>> Hmmmmm... in my UNSAFE INTERFACE I declare my special type as >>> REFANY (see the URL I sent a few messages ago). >>> >>> Since you can't deref REFANY, I'm thinking that... it's mainly a >>> problem with TYPECASE, TYPECODE, and ISTYPE...? (In safe code, >>> that is.) >>> >>> Also the GC would have to know that refs that are # 0 (mod 4) aren't >>> real references and not try to follow those. As long as they are >>> on the stack or in registers there's not much you can do... >>> >>> I don't think this is all that difficult. My example code has a >>> very >>> simple API of the kind you describe. See SmallInteger.[im]3... >>> >>> Mika >>> >>> Tony Hosking writes: >>>> Sorry, yes, I am not awake yet this morning. Need more coffeee. Of >>>> course this occurs even for all untagged values. >>>> >>>> The main problem is that it would be dangerous generally to allow >>>> reference fields to contain tagged values, since then even safe >>>> code >>>> could try to dereference what would amount to actually being a >>>> tagged >>>> value non-reference. What we really need is a new type "tagged >>>> reference" distinct from normal references with associated API to >>>> extract the reference/value it holds. The compiler would need to >>>> generate heap maps that include these for processing by the >>>> collector, >>>> just as it does for ordinary references. >>>> >>>> On 30 Mar 2009, at 10:49, Mika Nystrom wrote: >>>> >>>>> Tony, >>>>> >>>>> Doesn't this already happen with INTEGER, REAL, LONGREAL, etc., >>>>> objects? >>>>> >>>>> Mika >>>>> >>>>> Tony Hosking writes: >>>>>> If we could accurately type values in the stack/registers at run >>>>>> time >>>>>> then this would not be a problem. Unfortunately, the compiler >>>>>> does >>>>>> not do this, so it is possible for a derived pointer (reference + >>>>>> offset) to be formed in stack/registers that the garbage >>>>>> collector >>>>>> won't be able to distinguish between one of your tagged values >>>>>> and >>>>>> some derived pointer into the middle of an object. If we could >>>>>> assume >>>>>> that the heap never allocates from some known set of addresses >>>>>> then >>>>>> we >>>>>> could safely distinguish the tagged values. >>>>>> >>>>>> On 30 Mar 2009, at 06:10, hendrik at topoi.pooq.com wrote: >>>>>> >>>>>>> There are many times I want to express data which could be >>>>>>> efficiently >>>>>>> coded as the disjoing union of (small) integer and pointer to >>>>>>> object. >>>>>>> The pointer-to-object is used in the case where tho objects are >>>>>>> big; >>>>>>> the (small) integer for the more common case where the objects >>>>>>> are >>>>>>> small. >>>>>>> >>>>>>> High-level languages seem to pe quite paranoid about admitting >>>>>>> thise >>>>>>> kind of data into the fold, except maybe for Lisp systems, which >>>>>>> have >>>>>>> been doing this from time immemorial. (I believe CAML does >>>>>>> this, >>>>>>> too). >>>>>>> These languages use it internally, and manage to (mostly) hide >>>>>>> it >>>>>>> from >>>>>>> the user. >>>>>>> >>>>>>> The X toolkit uses this trick too -- there's a constant >>>>>>> somewhere, >>>>>>> and >>>>>>> if an integer is less than this constant, it's passed to an X >>>>>>> toolkit >>>>>>> function as an integer; otherwise by reference. The idea >>>>>>> there is >>>>>>> that >>>>>>> there's a range of addresses of storage that can never be used >>>>>>> as >>>>>>> parameters for the X toolkit functions (presumably because of >>>>>>> hardware >>>>>>> or OS limitations), and that the bit patterns that are >>>>>>> unavailable >>>>>>> for >>>>>>> addresses can be used as small integers. >>>>>>> >>>>>>> Now the semantics of such a union, efficiently coded, are quite >>>>>>> clear. >>>>>>> There's a range of numbers that can be packed unamiguously into >>>>>>> pointers, and if your integer can be so packed, you do it; >>>>>>> otherwise you use a reference to sime kind of INTEGER object >>>>>>> elsewhere. There are operations for packing integers and object >>>>>>> pointers into such words, and others for unpacking them >>>>>>> (complete >>>>>>> with >>>>>>> type-test). The actual physical representation can be >>>>>>> machine- or >>>>>>> implemetation dependent -- you could do a bit of shifting and >>>>>>> pack >>>>>>> integers into words with the low bit set (if pointers to objects >>>>>>> are >>>>>>> usually aligned in some way, the integers will stand out as >>>>>>> being >>>>>>> unalinged) Or you could use an uppoer bound on "small" >>>>>>> integers, >>>>>>> as C >>>>>>> does. And on a machine where such packing is impossible (for >>>>>>> whatever >>>>>>> reason) you could simply set the upper bound of (the absolute >>>>>>> alue >>>>>>> of) such packable integers to be zero, so there wouldn't be any. >>>>>>> >>>>>>> Is there any way such a thing can be done in Modula 3? Remember >>>>>>> -- >>>>>>> I do >>>>>>> want the garbage collector to be aware of such conventions and >>>>>>> do >>>>>>> proper >>>>>>> tracing on the pointers? >>>>>>> >>>>>>> (I suspect the answer is "no". But would be a pity.) >>>>>>> >>>>>>> -- hendrik >>>> >> From hendrik at topoi.pooq.com Mon Mar 30 15:19:18 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 30 Mar 2009 09:19:18 -0400 Subject: [M3devel] m3 CVS? In-Reply-To: References: <20090325083158.hkinn8yjkksocw4c@mail.elegosoft.com> <20090325135234.GA16351@topoi.pooq.com> <20090325163537.mcnrz1ekw00ks8sg@mail.elegosoft.com> <20090325144505.GA16526@topoi.pooq.com> <20090325225421.GB17118@topoi.pooq.com> Message-ID: <20090330131918.GA6921@topoi.pooq.com> On Thu, Mar 26, 2009 at 02:08:00AM +0000, Jay wrote: > > > > svn is at least somewhat better than cvs. > > > > In http://gravityboy.livejournal.com/39755.html, gravityboy says > > > > : I'm really tired of people pushing the adoption of svn because it's a > > : better CVS. The only people who that argument hasn't swayed are those > > > > > That's ambiguous to me. > > He isn't clearly opposed to adopting svn over cvs, but svn over anything else. > > It doesn't matter what I think, but I'm definitely not opposed to monotone. > > Its marketing material reads among the best (seriously). > > > > > > I'm not volunteering to do any conversion, and I'm sure I (and others) will grumble no matter how painless switching clients is, but I'm pretty sure there are gains to be had and ignore at least my grumbling. > > I really don't like the web interface to CVS in particular. It doesn't let me identify "change sets" and view their diffs, I have to root around to all the files. Tinderbox does address this, on the side. (You would have to be sure, whatever replacement/conversion, included a web interface, anonymous read-only access, Tinderbox-or-other interop, etc.; imho you don't have to deliver all at once.) > > > > > > The source control systems that use "databases", which I think monotone does, do they interact poorly with backup (in particular, whatever backup Elegosoft uses)? You know -- an incremental backup system that looks at file times/sizes would end up always copying the entire thing. Even so, "databases" can be a good thing.. > > > > > > I understand that "two way migration" lets people keep using either > system, but I'm not sure that's worthwhile. On the other hand, if "the > new way" is read/write, and a "cvs mirror" is read only, except for > some blessed mirroring server, that should be fairly easy and have > some value. That can also be a way to ease the transition wrt > anonymous read-only access, Tinderbox interop, etc. Is CVS back up yet? Completely? I've been delaying trying the monotone conversion because it would be nice to have only one set of problems to look into. -- hendrik > > > > > > - Jay > > From jay.krell at cornell.edu Mon Mar 30 15:23:10 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 30 Mar 2009 13:23:10 +0000 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: This was surprisingly difficult. InitHandlers is called much earlier than InitActivations. InitActivations does a heap allocation. InitHandlers did not. The types involved are not yet initialized at this point, or somesuch. You cannot NEW(Activation) in the first call to PushFrame. So, maybe, use a global for the first one, but then what happens is it gets reinitialized later by the module initializer -- which is perhaps another indictment of initializers..or maybe a special case in the depths of the system -- this module and anything it uses are subject to be called by compiler-generated calls -- they can be called before their initializers run.. seems to me the initialization could have happened "statically" like in C. Anyway, I should have this done shortly. Trick is to use a local value and assign it to a heap block allocated directly with calloc instead of RTAllocator. The result is maybe faster, maybe slower. Before, "try" cost pthread_getspecific and setspecific. Now it will just cost getspecific. But with another pointer deref and call to GetActivation with its on-demand initialization. Before, popframe only called setspecific. Now it will only call getspecific, plus the indirect and on-demand initialization. The on-demand seems bogus in pop, given that push already had to occur. So maybe that could be optimized. This stuff is highly optimized in C and C++ on NT.. NT/x86 has a special thread local just for exception handling, faster than all other thread locals. All non-x86 NT platforms have stack walkers -- no cost for "try", and then "throw" maps instruction pointer to data about how to to unwind the stack, using a little mini-assembly code. - Jay ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 19 Mar 2009 01:03:57 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] per thread data? > > > > > > > > > Thanks, I should get around to that "soon" then. > > > > - Jay > > > > ________________________________ > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 19 Mar 2009 10:14:59 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] per thread data? > > I have no problem putting the exception handler stack thread local into the activation thread local. > > > > > > > On 18 Mar 2009, at 20:11, Jay wrote: > > > > I'm not looking at it right now, but doesn't seem rather piggy to have two thread locals and data on the side? > > > I'm guessing the data on the side is needed because we need to be able to enumerate our threads, to suspend them all? > > > I understand that having multiple thread locals optimizes their use, but it seems greedy. > vs. a small heap allocation that combines them. > > Or in fact.. presumably there could just be one thread local that is the thread pointer, and the handler link could be put at the start, for architectures where zero offset is smaller/faster than non-zero offset. > > > Another idea, of course, is to look into "__thread", "__declspec(thread)". > > On Windows and probably all platforms they exist on, they are nicely more efficient than pthread_get/setspecific, except on Windows they don't really work acceptably prior to Vista -- they only work in .exes and their static dependencies, not any .dll you load after the process starts with LoadLibrary (dlopen). > > > Does "__thread" work well on most non-Windows platforms? > i.e. even if shared object is loaded with dlopen? > > > I could have sworn I saw code out there that was "adaptive". > It easily/efficiently checked if it was loaded with LoadLibrary or not. > If so, it'd TlsGet/SetValue (pthread_get/setspecific). > If not, it'd use __declspec(thread) (__thread). > The check was based on if __tlsindex was not zero or somesuch. I couldn't track it down though. > > > In either case, yes, I know, one of the thread locals at least is gone on platforms that have stack walkers, e.g. Solaris, and potentially NT, and maybe others. > > > - Jay > > From jay.krell at cornell.edu Tue Mar 31 00:15:29 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 30 Mar 2009 22:15:29 +0000 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: hm, thinking about this more... What about threads not created by Modula-3 Fork() (or the first thread)? It looks like exception handling had a chance of working on them before. Now they'll crash upon entering functions with try or raise or I presume lock. 1) ok? 2) do the heap alloc on demand? But is that enough? Can it be initialized without further context? Let's see..the circular list can be maintained without further context. handle := pthread_self, ok. stack can probably be figured out, though that is probably just for gc and could be left alone for now, continuing to not work (or fixed)...getcontext at least on some platforms can fill this in, or VirtualQuery/msomething (mmap family?)? 3) put back the second thread local? #2 has a chance of working better than before -- letting GC work on threads not created by Modula-3 runtime, something that has long bothered me...but I haven't done a complete analysis. Or at least maybe keep it working as it was For now there is somewhat of a regression, ie, when calling Modula-3 code on threads not created from Modula-3. Possibly the gc in this case was already dangerous? Failing to find references on other stacks? Or failing all allocations (should be easy to check but I have to run..) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] per thread data? > Date: Mon, 30 Mar 2009 13:23:10 +0000 > > > This was surprisingly difficult. > > > InitHandlers is called much earlier than InitActivations. > InitActivations does a heap allocation. > InitHandlers did not. > The types involved are not yet initialized at this point, or somesuch. > You cannot NEW(Activation) in the first call to PushFrame. > So, maybe, use a global for the first one, > but then what happens is it gets reinitialized later by > the module initializer -- which is perhaps another indictment > of initializers..or maybe a special case in the depths of the system -- > this module and anything it uses are subject to be called by > compiler-generated calls -- they can be called before their initializers > run.. seems to me the initialization could have happened "statically" > like in C. > > > Anyway, I should have this done shortly. > Trick is to use a local value and assign it to a heap block > allocated directly with calloc instead of RTAllocator. > > > The result is maybe faster, maybe slower. > Before, "try" cost pthread_getspecific and setspecific. > Now it will just cost getspecific. > But with another pointer deref and call to GetActivation > with its on-demand initialization. > > > Before, popframe only called setspecific. > Now it will only call getspecific, plus the indirect > and on-demand initialization. > The on-demand seems bogus in pop, given that push already had to occur. > So maybe that could be optimized. > > > This stuff is highly optimized in C and C++ on NT.. > NT/x86 has a special thread local just for exception handling, > faster than all other thread locals. > All non-x86 NT platforms have stack walkers -- no cost for "try", > and then "throw" maps instruction pointer to data about how to > to unwind the stack, using a little mini-assembly code. > > > - Jay > > > ________________________________ >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Thu, 19 Mar 2009 01:03:57 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] per thread data? >> >> >> >> >> >> >> >> >> Thanks, I should get around to that "soon" then. >> >> >> >> - Jay >> >> >> >> ________________________________ >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Thu, 19 Mar 2009 10:14:59 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] per thread data? >> >> I have no problem putting the exception handler stack thread local into the activation thread local. >> >> >> >> >> >> >> On 18 Mar 2009, at 20:11, Jay wrote: >> >> >> >> I'm not looking at it right now, but doesn't seem rather piggy to have two thread locals and data on the side? >> >> >> I'm guessing the data on the side is needed because we need to be able to enumerate our threads, to suspend them all? >> >> >> I understand that having multiple thread locals optimizes their use, but it seems greedy. >> vs. a small heap allocation that combines them. >> >> Or in fact.. presumably there could just be one thread local that is the thread pointer, and the handler link could be put at the start, for architectures where zero offset is smaller/faster than non-zero offset. >> >> >> Another idea, of course, is to look into "__thread", "__declspec(thread)". >> >> On Windows and probably all platforms they exist on, they are nicely more efficient than pthread_get/setspecific, except on Windows they don't really work acceptably prior to Vista -- they only work in .exes and their static dependencies, not any .dll you load after the process starts with LoadLibrary (dlopen). >> >> >> Does "__thread" work well on most non-Windows platforms? >> i.e. even if shared object is loaded with dlopen? >> >> >> I could have sworn I saw code out there that was "adaptive". >> It easily/efficiently checked if it was loaded with LoadLibrary or not. >> If so, it'd TlsGet/SetValue (pthread_get/setspecific). >> If not, it'd use __declspec(thread) (__thread). >> The check was based on if __tlsindex was not zero or somesuch. I couldn't track it down though. >> >> >> In either case, yes, I know, one of the thread locals at least is gone on platforms that have stack walkers, e.g. Solaris, and potentially NT, and maybe others. >> >> >> - Jay >> >> From hosking at cs.purdue.edu Tue Mar 31 00:42:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Mar 2009 09:42:06 +1100 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: Yes, this is a tricky issue. At some point I seem to recall it being OK to have non-Modula-3 threads start running Modula-3 code, but I don't know for sure. I've never really liked the idea of having non- M3 threads. Are you using the existing handler maps and exception stack unwinding support for non-x86 NT? On 31 Mar 2009, at 09:15, Jay wrote: > > hm, thinking about this more... > What about threads not created by Modula-3 Fork() (or the first > thread)? > > It looks like exception handling had a chance of working on them > before. Now they'll crash upon entering functions > with try or raise or I presume lock. > > > 1) ok? > > > 2) do the heap alloc on demand? > But is that enough? Can it be initialized without further context? > Let's see..the circular list can be maintained without further > context. > handle := pthread_self, ok. stack can probably be figured out, though > that is probably just for gc and could be left alone for now, > continuing > to not work (or fixed)...getcontext at least on some platforms can > fill this in, or VirtualQuery/msomething (mmap family?)? > > > 3) put back the second thread local? > > > #2 has a chance of working better than before -- letting GC > work on threads not created by Modula-3 runtime, something > that has long bothered me...but I haven't done a complete analysis. > Or at least maybe keep it working as it was > For now there is somewhat of a regression, ie, when calling > Modula-3 code on threads not created from Modula-3. > Possibly the gc in this case was already dangerous? > Failing to find references on other stacks? > Or failing all allocations (should be easy to check but I have to > run..) > > > - Jay > > > > > > > > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] per thread data? >> Date: Mon, 30 Mar 2009 13:23:10 +0000 >> >> >> This was surprisingly difficult. >> >> >> InitHandlers is called much earlier than InitActivations. >> InitActivations does a heap allocation. >> InitHandlers did not. >> The types involved are not yet initialized at this point, or >> somesuch. >> You cannot NEW(Activation) in the first call to PushFrame. >> So, maybe, use a global for the first one, >> but then what happens is it gets reinitialized later by >> the module initializer -- which is perhaps another indictment >> of initializers..or maybe a special case in the depths of the >> system -- >> this module and anything it uses are subject to be called by >> compiler-generated calls -- they can be called before their >> initializers >> run.. seems to me the initialization could have happened "statically" >> like in C. >> >> >> Anyway, I should have this done shortly. >> Trick is to use a local value and assign it to a heap block >> allocated directly with calloc instead of RTAllocator. >> >> >> The result is maybe faster, maybe slower. >> Before, "try" cost pthread_getspecific and setspecific. >> Now it will just cost getspecific. >> But with another pointer deref and call to GetActivation >> with its on-demand initialization. >> >> >> Before, popframe only called setspecific. >> Now it will only call getspecific, plus the indirect >> and on-demand initialization. >> The on-demand seems bogus in pop, given that push already had to >> occur. >> So maybe that could be optimized. >> >> >> This stuff is highly optimized in C and C++ on NT.. >> NT/x86 has a special thread local just for exception handling, >> faster than all other thread locals. >> All non-x86 NT platforms have stack walkers -- no cost for "try", >> and then "throw" maps instruction pointer to data about how to >> to unwind the stack, using a little mini-assembly code. >> >> >> - Jay >> >> >> ________________________________ >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Thu, 19 Mar 2009 01:03:57 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] per thread data? >>> >>> >>> >>> >>> >>> >>> >>> >>> Thanks, I should get around to that "soon" then. >>> >>> >>> >>> - Jay >>> >>> >>> >>> ________________________________ >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Thu, 19 Mar 2009 10:14:59 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] per thread data? >>> >>> I have no problem putting the exception handler stack thread local >>> into the activation thread local. >>> >>> >>> >>> >>> >>> >>> On 18 Mar 2009, at 20:11, Jay wrote: >>> >>> >>> >>> I'm not looking at it right now, but doesn't seem rather piggy to >>> have two thread locals and data on the side? >>> >>> >>> I'm guessing the data on the side is needed because we need to be >>> able to enumerate our threads, to suspend them all? >>> >>> >>> I understand that having multiple thread locals optimizes their >>> use, but it seems greedy. >>> vs. a small heap allocation that combines them. >>> >>> Or in fact.. presumably there could just be one thread local that >>> is the thread pointer, and the handler link could be put at the >>> start, for architectures where zero offset is smaller/faster than >>> non-zero offset. >>> >>> >>> Another idea, of course, is to look into "__thread", >>> "__declspec(thread)". >>> >>> On Windows and probably all platforms they exist on, they are >>> nicely more efficient than pthread_get/setspecific, except on >>> Windows they don't really work acceptably prior to Vista -- they >>> only work in .exes and their static dependencies, not any .dll you >>> load after the process starts with LoadLibrary (dlopen). >>> >>> >>> Does "__thread" work well on most non-Windows platforms? >>> i.e. even if shared object is loaded with dlopen? >>> >>> >>> I could have sworn I saw code out there that was "adaptive". >>> It easily/efficiently checked if it was loaded with LoadLibrary or >>> not. >>> If so, it'd TlsGet/SetValue (pthread_get/setspecific). >>> If not, it'd use __declspec(thread) (__thread). >>> The check was based on if __tlsindex was not zero or somesuch. I >>> couldn't track it down though. >>> >>> >>> In either case, yes, I know, one of the thread locals at least is >>> gone on platforms that have stack walkers, e.g. Solaris, and >>> potentially NT, and maybe others. >>> >>> >>> - Jay >>> >>> From hosking at cs.purdue.edu Tue Mar 31 00:44:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Mar 2009 09:44:02 +1100 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: <6B76EEF4-F926-4CF6-AF77-0D32A4A7D438@cs.purdue.edu> I am a little uneasy about calloc being used instead of RTAllocator. We lose the single point of allocation that is useful for all sorts of things like accounting, etc. I'll take a look at what you have done and think about it some... On 31 Mar 2009, at 09:15, Jay wrote: > > hm, thinking about this more... > What about threads not created by Modula-3 Fork() (or the first > thread)? > > > It looks like exception handling had a chance of working on them > before. Now they'll crash upon entering functions > with try or raise or I presume lock. > > > 1) ok? > > > 2) do the heap alloc on demand? > But is that enough? Can it be initialized without further context? > Let's see..the circular list can be maintained without further > context. > handle := pthread_self, ok. stack can probably be figured out, though > that is probably just for gc and could be left alone for now, > continuing > to not work (or fixed)...getcontext at least on some platforms can > fill this in, or VirtualQuery/msomething (mmap family?)? > > > 3) put back the second thread local? > > > #2 has a chance of working better than before -- letting GC > work on threads not created by Modula-3 runtime, something > that has long bothered me...but I haven't done a complete analysis. > Or at least maybe keep it working as it was > For now there is somewhat of a regression, ie, when calling > Modula-3 code on threads not created from Modula-3. > Possibly the gc in this case was already dangerous? > Failing to find references on other stacks? > Or failing all allocations (should be easy to check but I have to > run..) > > > - Jay > > > > > > > > > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] per thread data? >> Date: Mon, 30 Mar 2009 13:23:10 +0000 >> >> >> This was surprisingly difficult. >> >> >> InitHandlers is called much earlier than InitActivations. >> InitActivations does a heap allocation. >> InitHandlers did not. >> The types involved are not yet initialized at this point, or >> somesuch. >> You cannot NEW(Activation) in the first call to PushFrame. >> So, maybe, use a global for the first one, >> but then what happens is it gets reinitialized later by >> the module initializer -- which is perhaps another indictment >> of initializers..or maybe a special case in the depths of the >> system -- >> this module and anything it uses are subject to be called by >> compiler-generated calls -- they can be called before their >> initializers >> run.. seems to me the initialization could have happened "statically" >> like in C. >> >> >> Anyway, I should have this done shortly. >> Trick is to use a local value and assign it to a heap block >> allocated directly with calloc instead of RTAllocator. >> >> >> The result is maybe faster, maybe slower. >> Before, "try" cost pthread_getspecific and setspecific. >> Now it will just cost getspecific. >> But with another pointer deref and call to GetActivation >> with its on-demand initialization. >> >> >> Before, popframe only called setspecific. >> Now it will only call getspecific, plus the indirect >> and on-demand initialization. >> The on-demand seems bogus in pop, given that push already had to >> occur. >> So maybe that could be optimized. >> >> >> This stuff is highly optimized in C and C++ on NT.. >> NT/x86 has a special thread local just for exception handling, >> faster than all other thread locals. >> All non-x86 NT platforms have stack walkers -- no cost for "try", >> and then "throw" maps instruction pointer to data about how to >> to unwind the stack, using a little mini-assembly code. >> >> >> - Jay >> >> >> ________________________________ >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Thu, 19 Mar 2009 01:03:57 +0000 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] per thread data? >>> >>> >>> >>> >>> >>> >>> >>> >>> Thanks, I should get around to that "soon" then. >>> >>> >>> >>> - Jay >>> >>> >>> >>> ________________________________ >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Thu, 19 Mar 2009 10:14:59 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] per thread data? >>> >>> I have no problem putting the exception handler stack thread local >>> into the activation thread local. >>> >>> >>> >>> >>> >>> >>> On 18 Mar 2009, at 20:11, Jay wrote: >>> >>> >>> >>> I'm not looking at it right now, but doesn't seem rather piggy to >>> have two thread locals and data on the side? >>> >>> >>> I'm guessing the data on the side is needed because we need to be >>> able to enumerate our threads, to suspend them all? >>> >>> >>> I understand that having multiple thread locals optimizes their >>> use, but it seems greedy. >>> vs. a small heap allocation that combines them. >>> >>> Or in fact.. presumably there could just be one thread local that >>> is the thread pointer, and the handler link could be put at the >>> start, for architectures where zero offset is smaller/faster than >>> non-zero offset. >>> >>> >>> Another idea, of course, is to look into "__thread", >>> "__declspec(thread)". >>> >>> On Windows and probably all platforms they exist on, they are >>> nicely more efficient than pthread_get/setspecific, except on >>> Windows they don't really work acceptably prior to Vista -- they >>> only work in .exes and their static dependencies, not any .dll you >>> load after the process starts with LoadLibrary (dlopen). >>> >>> >>> Does "__thread" work well on most non-Windows platforms? >>> i.e. even if shared object is loaded with dlopen? >>> >>> >>> I could have sworn I saw code out there that was "adaptive". >>> It easily/efficiently checked if it was loaded with LoadLibrary or >>> not. >>> If so, it'd TlsGet/SetValue (pthread_get/setspecific). >>> If not, it'd use __declspec(thread) (__thread). >>> The check was based on if __tlsindex was not zero or somesuch. I >>> couldn't track it down though. >>> >>> >>> In either case, yes, I know, one of the thread locals at least is >>> gone on platforms that have stack walkers, e.g. Solaris, and >>> potentially NT, and maybe others. >>> >>> >>> - Jay >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Mar 31 00:45:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Mar 2009 09:45:22 +1100 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: <21521BC5-BC0A-4852-A624-AF948D66C575@cs.purdue.edu> PS In general, I am loathe to make changes that complicate the code based on performance assumptions that are only hypothetical. Better to profile and see where the time is going before prematurely "optimizing". On 31 Mar 2009, at 09:42, Tony Hosking wrote: > Yes, this is a tricky issue. At some point I seem to recall it > being OK to have non-Modula-3 threads start running Modula-3 code, > but I don't know for sure. I've never really liked the idea of > having non-M3 threads. > > Are you using the existing handler maps and exception stack > unwinding support for non-x86 NT? > > On 31 Mar 2009, at 09:15, Jay wrote: > >> >> hm, thinking about this more... >> What about threads not created by Modula-3 Fork() (or the first >> thread)? >> >> It looks like exception handling had a chance of working on them >> before. Now they'll crash upon entering functions >> with try or raise or I presume lock. >> >> >> 1) ok? >> >> >> 2) do the heap alloc on demand? >> But is that enough? Can it be initialized without further context? >> Let's see..the circular list can be maintained without further >> context. >> handle := pthread_self, ok. stack can probably be figured out, though >> that is probably just for gc and could be left alone for now, >> continuing >> to not work (or fixed)...getcontext at least on some platforms can >> fill this in, or VirtualQuery/msomething (mmap family?)? >> >> >> 3) put back the second thread local? >> >> >> #2 has a chance of working better than before -- letting GC >> work on threads not created by Modula-3 runtime, something >> that has long bothered me...but I haven't done a complete analysis. >> Or at least maybe keep it working as it was >> For now there is somewhat of a regression, ie, when calling >> Modula-3 code on threads not created from Modula-3. >> Possibly the gc in this case was already dangerous? >> Failing to find references on other stacks? >> Or failing all allocations (should be easy to check but I have to >> run..) >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] per thread data? >>> Date: Mon, 30 Mar 2009 13:23:10 +0000 >>> >>> >>> This was surprisingly difficult. >>> >>> >>> InitHandlers is called much earlier than InitActivations. >>> InitActivations does a heap allocation. >>> InitHandlers did not. >>> The types involved are not yet initialized at this point, or >>> somesuch. >>> You cannot NEW(Activation) in the first call to PushFrame. >>> So, maybe, use a global for the first one, >>> but then what happens is it gets reinitialized later by >>> the module initializer -- which is perhaps another indictment >>> of initializers..or maybe a special case in the depths of the >>> system -- >>> this module and anything it uses are subject to be called by >>> compiler-generated calls -- they can be called before their >>> initializers >>> run.. seems to me the initialization could have happened >>> "statically" >>> like in C. >>> >>> >>> Anyway, I should have this done shortly. >>> Trick is to use a local value and assign it to a heap block >>> allocated directly with calloc instead of RTAllocator. >>> >>> >>> The result is maybe faster, maybe slower. >>> Before, "try" cost pthread_getspecific and setspecific. >>> Now it will just cost getspecific. >>> But with another pointer deref and call to GetActivation >>> with its on-demand initialization. >>> >>> >>> Before, popframe only called setspecific. >>> Now it will only call getspecific, plus the indirect >>> and on-demand initialization. >>> The on-demand seems bogus in pop, given that push already had to >>> occur. >>> So maybe that could be optimized. >>> >>> >>> This stuff is highly optimized in C and C++ on NT.. >>> NT/x86 has a special thread local just for exception handling, >>> faster than all other thread locals. >>> All non-x86 NT platforms have stack walkers -- no cost for "try", >>> and then "throw" maps instruction pointer to data about how to >>> to unwind the stack, using a little mini-assembly code. >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> Date: Thu, 19 Mar 2009 01:03:57 +0000 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] per thread data? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thanks, I should get around to that "soon" then. >>>> >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> From: hosking at cs.purdue.edu >>>> To: jay.krell at cornell.edu >>>> Date: Thu, 19 Mar 2009 10:14:59 +1100 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] per thread data? >>>> >>>> I have no problem putting the exception handler stack thread >>>> local into the activation thread local. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 18 Mar 2009, at 20:11, Jay wrote: >>>> >>>> >>>> >>>> I'm not looking at it right now, but doesn't seem rather piggy to >>>> have two thread locals and data on the side? >>>> >>>> >>>> I'm guessing the data on the side is needed because we need to be >>>> able to enumerate our threads, to suspend them all? >>>> >>>> >>>> I understand that having multiple thread locals optimizes their >>>> use, but it seems greedy. >>>> vs. a small heap allocation that combines them. >>>> >>>> Or in fact.. presumably there could just be one thread local that >>>> is the thread pointer, and the handler link could be put at the >>>> start, for architectures where zero offset is smaller/faster than >>>> non-zero offset. >>>> >>>> >>>> Another idea, of course, is to look into "__thread", >>>> "__declspec(thread)". >>>> >>>> On Windows and probably all platforms they exist on, they are >>>> nicely more efficient than pthread_get/setspecific, except on >>>> Windows they don't really work acceptably prior to Vista -- they >>>> only work in .exes and their static dependencies, not any .dll >>>> you load after the process starts with LoadLibrary (dlopen). >>>> >>>> >>>> Does "__thread" work well on most non-Windows platforms? >>>> i.e. even if shared object is loaded with dlopen? >>>> >>>> >>>> I could have sworn I saw code out there that was "adaptive". >>>> It easily/efficiently checked if it was loaded with LoadLibrary >>>> or not. >>>> If so, it'd TlsGet/SetValue (pthread_get/setspecific). >>>> If not, it'd use __declspec(thread) (__thread). >>>> The check was based on if __tlsindex was not zero or somesuch. I >>>> couldn't track it down though. >>>> >>>> >>>> In either case, yes, I know, one of the thread locals at least is >>>> gone on platforms that have stack walkers, e.g. Solaris, and >>>> potentially NT, and maybe others. >>>> >>>> >>>> - Jay >>>> >>>> From jay.krell at cornell.edu Tue Mar 31 02:06:04 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 31 Mar 2009 00:06:04 +0000 Subject: [M3devel] per thread data? In-Reply-To: References: Message-ID: My point about optimized thread locals was about C and C++. (And not gcc, at that.) Modula-3 on NT is the same as "all" platforms, except, I guess, Solaris/SPARC32. No stack walker. Highly inefficient pushframe/popframe using general thread locals -- pthread_getspecific/setspecific / TlsGetValue/SetValue -- pthreads and Win32 are very analogous here. There is only NT/x86 for Modula-3 so far. I'm not sure gcc for NT/amd64 is mature enough, and haven't seen any signs of NT/IA64 (nor Alpha/PPC/MIPS...). gcc on NT/x86 has its own other two EH mechanisms -- setjmp/longjmp and I presume a stack walking implementation. Most other compilers are like Visual C++ -- e.g. OpenWatcom and DigitalMars. CodeWarrior had two settings, I think one matched Visual C++. There should really be just one implementation of this across all languages. NT's setjmp/longjmp do interoperate with exceptions at least, so you can use a portable slow form and still interoperate..well, there are two versions, one that does, one that doesn't. I need to switch Modula-3 to the interoperable form. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] per thread data? > Date: Tue, 31 Mar 2009 09:42:06 +1100 > > Yes, this is a tricky issue. At some point I seem to recall it being > OK to have non-Modula-3 threads start running Modula-3 code, but I > don't know for sure. I've never really liked the idea of having non- > M3 threads. > > Are you using the existing handler maps and exception stack unwinding > support for non-x86 NT? > > On 31 Mar 2009, at 09:15, Jay wrote: > > > > > hm, thinking about this more... > > What about threads not created by Modula-3 Fork() (or the first > > thread)? > > > > It looks like exception handling had a chance of working on them > > before. Now they'll crash upon entering functions > > with try or raise or I presume lock. > > > > > > 1) ok? > > > > > > 2) do the heap alloc on demand? > > But is that enough? Can it be initialized without further context? > > Let's see..the circular list can be maintained without further > > context. > > handle := pthread_self, ok. stack can probably be figured out, though > > that is probably just for gc and could be left alone for now, > > continuing > > to not work (or fixed)...getcontext at least on some platforms can > > fill this in, or VirtualQuery/msomething (mmap family?)? > > > > > > 3) put back the second thread local? > > > > > > #2 has a chance of working better than before -- letting GC > > work on threads not created by Modula-3 runtime, something > > that has long bothered me...but I haven't done a complete analysis. > > Or at least maybe keep it working as it was > > For now there is somewhat of a regression, ie, when calling > > Modula-3 code on threads not created from Modula-3. > > Possibly the gc in this case was already dangerous? > > Failing to find references on other stacks? > > Or failing all allocations (should be easy to check but I have to > > run..) > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu > >> CC: m3devel at elegosoft.com > >> Subject: RE: [M3devel] per thread data? > >> Date: Mon, 30 Mar 2009 13:23:10 +0000 > >> > >> > >> This was surprisingly difficult. > >> > >> > >> InitHandlers is called much earlier than InitActivations. > >> InitActivations does a heap allocation. > >> InitHandlers did not. > >> The types involved are not yet initialized at this point, or > >> somesuch. > >> You cannot NEW(Activation) in the first call to PushFrame. > >> So, maybe, use a global for the first one, > >> but then what happens is it gets reinitialized later by > >> the module initializer -- which is perhaps another indictment > >> of initializers..or maybe a special case in the depths of the > >> system -- > >> this module and anything it uses are subject to be called by > >> compiler-generated calls -- they can be called before their > >> initializers > >> run.. seems to me the initialization could have happened "statically" > >> like in C. > >> > >> > >> Anyway, I should have this done shortly. > >> Trick is to use a local value and assign it to a heap block > >> allocated directly with calloc instead of RTAllocator. > >> > >> > >> The result is maybe faster, maybe slower. > >> Before, "try" cost pthread_getspecific and setspecific. > >> Now it will just cost getspecific. > >> But with another pointer deref and call to GetActivation > >> with its on-demand initialization. > >> > >> > >> Before, popframe only called setspecific. > >> Now it will only call getspecific, plus the indirect > >> and on-demand initialization. > >> The on-demand seems bogus in pop, given that push already had to > >> occur. > >> So maybe that could be optimized. > >> > >> > >> This stuff is highly optimized in C and C++ on NT.. > >> NT/x86 has a special thread local just for exception handling, > >> faster than all other thread locals. > >> All non-x86 NT platforms have stack walkers -- no cost for "try", > >> and then "throw" maps instruction pointer to data about how to > >> to unwind the stack, using a little mini-assembly code. > >> > >> > >> - Jay > >> > >> > >> ________________________________ > >>> From: jay.krell at cornell.edu > >>> To: hosking at cs.purdue.edu > >>> Date: Thu, 19 Mar 2009 01:03:57 +0000 > >>> CC: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] per thread data? > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Thanks, I should get around to that "soon" then. > >>> > >>> > >>> > >>> - Jay > >>> > >>> > >>> > >>> ________________________________ > >>> > >>> From: hosking at cs.purdue.edu > >>> To: jay.krell at cornell.edu > >>> Date: Thu, 19 Mar 2009 10:14:59 +1100 > >>> CC: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] per thread data? > >>> > >>> I have no problem putting the exception handler stack thread local > >>> into the activation thread local. > >>> > >>> > >>> > >>> > >>> > >>> > >>> On 18 Mar 2009, at 20:11, Jay wrote: > >>> > >>> > >>> > >>> I'm not looking at it right now, but doesn't seem rather piggy to > >>> have two thread locals and data on the side? > >>> > >>> > >>> I'm guessing the data on the side is needed because we need to be