From rodney_bates at lcwb.coop Tue Jul 2 00:40:41 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 01 Jul 2013 17:40:41 -0500 Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? Message-ID: <51D20569.1010600@lcwb.coop> After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll total 792 -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp where parse.c is changed. When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l total 1944 -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c ../../gcc-4.7/gcc/m3cg/parse.c But parse.o has not changed (I can verify this by running gdb on cm3cg), and: rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll total 792 -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp My edits to parse.c have been undone! If I recreate the edited parse.c, then chmod 444 parse.c and recompile, it has no effect. parse.c still gets changed back to the unedited version. Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory (I have no idea how long this has been the case), and I have not been able to get cvs to admit to having any awareness of this directory or anything in it, using cvs log, cvs update or cvs checkout. I even tried manually creating a CVS subdirectory, but without getting cvs to tell me something about its current version number of parse.c, I can't create a line in CVS/Entries for it, and cvs continues to claim total ignorance of this file. What is going on here? Is parse.c (and all of m3cg) being automatically created? From where? cvs update -P does not remove m3cg, BTW. From jay.krell at cornell.edu Tue Jul 2 03:48:00 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 2 Jul 2013 01:48:00 +0000 Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? In-Reply-To: <51D20569.1010600@lcwb.coop> References: <51D20569.1010600@lcwb.coop> Message-ID: There is one parse.c for several gcc forks. It is copied or linked by m3makefile. - Jay > Date: Mon, 1 Jul 2013 17:40:41 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? > > > After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > total 792 > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp > > where parse.c is changed. > > When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l > total 1944 > -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c > ../../gcc-4.7/gcc/m3cg/parse.c > > But parse.o has not changed (I can verify this by running gdb on cm3cg), and: > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > total 792 > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp > > My edits to parse.c have been undone! If I recreate the edited parse.c, > then chmod 444 parse.c and recompile, it has no effect. parse.c still > gets changed back to the unedited version. > > Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory > (I have no idea how long this has been the case), and I have not been able > to get cvs to admit to having any awareness of this directory or anything in it, > using cvs log, cvs update or cvs checkout. I even tried manually creating a > CVS subdirectory, but without getting cvs to tell me something about its current > version number of parse.c, I can't create a line in CVS/Entries for it, and cvs > continues to claim total ignorance of this file. > > What is going on here? Is parse.c (and all of m3cg) being automatically created? > From where? > > cvs update -P does not remove m3cg, BTW. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Jul 2 16:31:26 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 02 Jul 2013 09:31:26 -0500 Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? In-Reply-To: References: <51D20569.1010600@lcwb.coop> Message-ID: <51D2E43E.8020803@lcwb.coop> OK. Is it the one in m3-sys/m3cc/gcc/gcc/m3cg? This has a CVS directory, while gcc-4.5 and gcc-4.7 do not, and m3-sys/m3cc-old doesn't sound promising. Does it work the same way for all the files in m3cg? On 07/01/2013 08:48 PM, Jay K wrote: > There is one parse.c for several gcc forks. It is copied or linked by m3makefile. > > - Jay > > > Date: Mon, 1 Jul 2013 17:40:41 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? > > > > > > After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > > total 792 > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > > -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp > > > > where parse.c is changed. > > > > When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l > > total 1944 > > -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c > > ../../gcc-4.7/gcc/m3cg/parse.c > > > > But parse.o has not changed (I can verify this by running gdb on cm3cg), and: > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > > total 792 > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp > > > > My edits to parse.c have been undone! If I recreate the edited parse.c, > > then chmod 444 parse.c and recompile, it has no effect. parse.c still > > gets changed back to the unedited version. > > > > Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory > > (I have no idea how long this has been the case), and I have not been able > > to get cvs to admit to having any awareness of this directory or anything in it, > > using cvs log, cvs update or cvs checkout. I even tried manually creating a > > CVS subdirectory, but without getting cvs to tell me something about its current > > version number of parse.c, I can't create a line in CVS/Entries for it, and cvs > > continues to claim total ignorance of this file. > > > > What is going on here? Is parse.c (and all of m3cg) being automatically created? > > From where? > > > > cvs update -P does not remove m3cg, BTW. > > > > From jay.krell at cornell.edu Wed Jul 3 03:56:05 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Jul 2013 01:56:05 +0000 Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? In-Reply-To: <51D2E43E.8020803@lcwb.coop> References: <51D20569.1010600@lcwb.coop> , <51D2E43E.8020803@lcwb.coop> Message-ID: Yes, there is just one copy of the directory. Look in m3cc/src/m3makefile. Sometimes maybe a prefix is copied followed by the rest of the file, e.g. #define GCC47 ... contents of parse.c ... The #defines have a mix of meanings. GCC12 might mean exactly GCC 1.2, or it might mean 1.2 or newer. And there is GCC_APPLE, which goes along with gcc 4.2. I'm sorry about that. It could/should be cleaned up. If you really want, consider some things: 1) make entire copies of the file 2) split the file up and copy some of them, while keeping others identical Most of the code is indeed identical. So I don't like #1. In the case of #2, the bulk of the content would remain where it is, in the one parse.c, so history would be reasonable. Preserving history is of some concern, but CVS works poorly enough, and perhaps we renamed the directories in the past, so I'd be ok with having to jump around to trace history accurately. Or leave things mostly asis. And/or cleanup the meanings or "granularity" of the #defines. And/or drop support for all but the latest? I didn't get around to moving every target forward. Mainline gcc does not support OpenBSD for example, so I/we always have to do at least a tiny bit of work there. The OpenBSD ports/packages system does maintain patches for gcc. Many are outside the backend, and they are all trivial, stuff like picking size_t and pre-#definining __OpenBSD__ or such. Interix also requires moving small non-Modula-3 patches forward. iPhone/ARM_DARWIN would remain at 4.2 also, probably. I got as far there as starting up the compiler, which is pretty far. I have a number of times edited the wrong file only to have it overwritten by m3makefile. That is an unfortunate fallout of this scheme. But, as I said, most of the contents of the file are portable across several gcc versions. Hopefully I'll back to the C backend and moot this.. :( Anyway, if you look at the source and CVS, it should be /reasonably/ clear. I don't know/remember what m3cc-old is. There is some pain around "GTY". The syntax for it changed across gcc versions, like GTY struct foo vs. struct GTY foo or struct foo GTY. This is the annotation you put on types for the gcc garbage collector. So for that I did split a little bit of content into a different file. - Jay > Date: Tue, 2 Jul 2013 09:31:26 -0500 > From: rodney_bates at lcwb.coop > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? > > OK. Is it the one in m3-sys/m3cc/gcc/gcc/m3cg? This has a CVS directory, while > gcc-4.5 and gcc-4.7 do not, and m3-sys/m3cc-old doesn't sound promising. > > Does it work the same way for all the files in m3cg? > > On 07/01/2013 08:48 PM, Jay K wrote: > > There is one parse.c for several gcc forks. It is copied or linked by m3makefile. > > > > - Jay > > > > > Date: Mon, 1 Jul 2013 17:40:41 -0500 > > > From: rodney_bates at lcwb.coop > > > To: m3devel at elegosoft.com > > > Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? > > > > > > > > > After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see > > > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > > > total 792 > > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > > > -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c > > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp > > > > > > where parse.c is changed. > > > > > > When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and > > > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l > > > total 1944 > > > -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c > > > ../../gcc-4.7/gcc/m3cg/parse.c > > > > > > But parse.o has not changed (I can verify this by running gdb on cm3cg), and: > > > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > > > total 792 > > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c > > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp > > > > > > My edits to parse.c have been undone! If I recreate the edited parse.c, > > > then chmod 444 parse.c and recompile, it has no effect. parse.c still > > > gets changed back to the unedited version. > > > > > > Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory > > > (I have no idea how long this has been the case), and I have not been able > > > to get cvs to admit to having any awareness of this directory or anything in it, > > > using cvs log, cvs update or cvs checkout. I even tried manually creating a > > > CVS subdirectory, but without getting cvs to tell me something about its current > > > version number of parse.c, I can't create a line in CVS/Entries for it, and cvs > > > continues to claim total ignorance of this file. > > > > > > What is going on here? Is parse.c (and all of m3cg) being automatically created? > > > From where? > > > > > > cvs update -P does not remove m3cg, BTW. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Jul 7 04:11:18 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 6 Jul 2013 22:11:18 -0400 Subject: [M3devel] Multiple executables from the same source Message-ID: <20130707021118.GA9726@topoi.pooq.com> I'm writiing and debugging a bunch of interfaces and modules. They are all supposed to fit together into one happy executable. But of course, until I've finished debugging them they fit together into one unhappy executable. To test them properly I'd like to write a series of unit tests. To run these tests I will need to make further executables, each consisting of a test modules and several of the modules under test. Now with the usual structure of a Modula 3 workspace, there is one m3makefile and a src directory, and it makes one executable, not many, and it doesn't really give me a choice of which executable I want. In the old days of C code and Makefiles, I could have multiple targets each one being built with its own cc command with its own list of source files names. Is there anything comparable for Modula 3? The best I've come up sith so far is to have a number of directories, one for each test case, with its own m3makefile and its own symbolic link to a common src directory. Is there something better? I'm not really interested in having all the test code be part of the final application. For one thing, I'd like to be able to test multiple implementations of a single interface, such as a reference implementation and an efficient one, so that I can compare the output and complain about the differences. -- hendrik From jay.krell at cornell.edu Sun Jul 7 07:46:03 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Jul 2013 05:46:03 +0000 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <20130707021118.GA9726@topoi.pooq.com> References: <20130707021118.GA9726@topoi.pooq.com> Message-ID: I think you have multiple obvious choices, that you are aware of, that you don't think you want: 1) put it all in one src, one executable, a command line switch to choice the test case, AND have an option in the m3makefile and Main.m3 to omit the test code 1b) or just live it with it all being present all the time 2) break out the code into multiple libraries and multiple executables; including having more stuff in your public interface than you otherwise would.. "Hey, look", I've worked with a few build systems. Mostly NT Build. There seems to be some Digital (DEC) line of descent visible in about half of the programming world, and Modula-3 and NT and NT Build live there. (The other half is Unix). m3quake and NT Build have an amazing coincidence in overall design and feel. They both are declarative with an escape. NT Build is actually a thin wrapper over nmake, such that many people don't realize nmake is there, but the escape is nmake/makefile.inc. m3quake/cm3 is its own language, the declarations are actually function calls, and the escape is the fairly general scripting language. Most people just use the declarative stuff and don't break out into the programming language. (NT Build is publically available in the Windows DDK, at least until recent versions.) They both limit, mostly, source files to be in leaf directories. You can't reach around and build random source from random other places. Unless you turn it into a library or .obj. NT Build does have an obscure little used feature named UMTEST/UMAPPL. Where you can build multiple test apps in one leaf. They are afforded one source file each, and I think link to the rest of the directory, i.e. a library. In specifying these test cases though, the full generality of what you can do in a directory is lost. In m3quake/cm3-speak -- consider "import". Which executable are you importing for? One special one? All of them? The same problems.. Given the successful scale of both of these systems (really, of NT build), I suggest the designers knew very well what they were doing and anything we complain is missing, they were probably actually doing us a favor by omitting, we should live with the limitations and be happy to have received such a decent scalable design. :) > with its own m3makefile and its own symbolic link to a common src directory. And how are you going to check that into CVS and sync and build it on file systems without symlinks? Not portable. - Jay > Date: Sat, 6 Jul 2013 22:11:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: [M3devel] Multiple executables from the same source > > I'm writiing and debugging a bunch of interfaces and modules. > They are all supposed to fit together into one happy executable. > > But of course, until I've finished debugging them > they fit together into one unhappy executable. > To test them properly I'd like to write a series of unit tests. > To run these tests I will need to make further executables, > each consisting of a test modules and several of the modules under test. > > Now with the usual structure of a Modula 3 workspace, > there is one m3makefile and a src directory, and it makes one executable, > not many, > and it doesn't really give me a choice of which executable I want. > > In the old days of C code and Makefiles, I could have multiple targets > each one being built with its own cc command > with its own list of source files names. > > Is there anything comparable for Modula 3? > > The best I've come up sith so far is to have a number of directories, > one for each test case, > with its own m3makefile and its own symbolic link to a common src directory. > > Is there something better? > > I'm not really interested in having all the test code > be part of the final application. > > For one thing, > I'd like to be able to test multiple implementations of a single interface, > such as a reference implementation and an efficient one, > so that I can compare the output and complain about the differences. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 7 10:13:42 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Jul 2013 08:13:42 +0000 Subject: [M3devel] Multiple executables from the same source In-Reply-To: References: <20130707021118.GA9726@topoi.pooq.com>, Message-ID: > I'd like to be able to test multiple implementations of a single interface, I suggest you use objects here. And a common base type. Like how "interface" is interpreted in Java, C#, and COM. Modula-3 supports this well enough, just with different terminology. - Jay From: jay.krell at cornell.edu To: hendrik at topoi.pooq.com; m3devel at elegosoft.com Date: Sun, 7 Jul 2013 05:46:03 +0000 Subject: Re: [M3devel] Multiple executables from the same source I think you have multiple obvious choices, that you are aware of, that you don't think you want: 1) put it all in one src, one executable, a command line switch to choice the test case, AND have an option in the m3makefile and Main.m3 to omit the test code 1b) or just live it with it all being present all the time 2) break out the code into multiple libraries and multiple executables; including having more stuff in your public interface than you otherwise would.. "Hey, look", I've worked with a few build systems. Mostly NT Build. There seems to be some Digital (DEC) line of descent visible in about half of the programming world, and Modula-3 and NT and NT Build live there. (The other half is Unix). m3quake and NT Build have an amazing coincidence in overall design and feel. They both are declarative with an escape. NT Build is actually a thin wrapper over nmake, such that many people don't realize nmake is there, but the escape is nmake/makefile.inc. m3quake/cm3 is its own language, the declarations are actually function calls, and the escape is the fairly general scripting language. Most people just use the declarative stuff and don't break out into the programming language. (NT Build is publically available in the Windows DDK, at least until recent versions.) They both limit, mostly, source files to be in leaf directories. You can't reach around and build random source from random other places. Unless you turn it into a library or .obj. NT Build does have an obscure little used feature named UMTEST/UMAPPL. Where you can build multiple test apps in one leaf. They are afforded one source file each, and I think link to the rest of the directory, i.e. a library. In specifying these test cases though, the full generality of what you can do in a directory is lost. In m3quake/cm3-speak -- consider "import". Which executable are you importing for? One special one? All of them? The same problems.. Given the successful scale of both of these systems (really, of NT build), I suggest the designers knew very well what they were doing and anything we complain is missing, they were probably actually doing us a favor by omitting, we should live with the limitations and be happy to have received such a decent scalable design. :) > with its own m3makefile and its own symbolic link to a common src directory. And how are you going to check that into CVS and sync and build it on file systems without symlinks? Not portable. - Jay > Date: Sat, 6 Jul 2013 22:11:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: [M3devel] Multiple executables from the same source > > I'm writiing and debugging a bunch of interfaces and modules. > They are all supposed to fit together into one happy executable. > > But of course, until I've finished debugging them > they fit together into one unhappy executable. > To test them properly I'd like to write a series of unit tests. > To run these tests I will need to make further executables, > each consisting of a test modules and several of the modules under test. > > Now with the usual structure of a Modula 3 workspace, > there is one m3makefile and a src directory, and it makes one executable, > not many, > and it doesn't really give me a choice of which executable I want. > > In the old days of C code and Makefiles, I could have multiple targets > each one being built with its own cc command > with its own list of source files names. > > Is there anything comparable for Modula 3? > > The best I've come up sith so far is to have a number of directories, > one for each test case, > with its own m3makefile and its own symbolic link to a common src directory. > > Is there something better? > > I'm not really interested in having all the test code > be part of the final application. > > For one thing, > I'd like to be able to test multiple implementations of a single interface, > such as a reference implementation and an efficient one, > so that I can compare the output and complain about the differences. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Jul 7 15:08:12 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 7 Jul 2013 09:08:12 -0400 Subject: [M3devel] Multiple executables from the same source In-Reply-To: References: <20130707021118.GA9726@topoi.pooq.com> Message-ID: <20130707130811.GA9183@topoi.pooq.com> On Sun, Jul 07, 2013 at 05:46:03AM +0000, Jay K wrote: > > And how are you going to check that into CVS and sync and build it on file systems without symlinks? Instead of CVS I use monotone, which does handle symbolic links. Or I could have a makefile that makes the symbolic links as needed. > Not portable. Yes, that bothers me. It's one of the reasons the symbolic link seemed like a kludge to me. I'll look into your suggestions. -- hendrik From hendrik at topoi.pooq.com Sun Jul 7 17:58:18 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 7 Jul 2013 11:58:18 -0400 Subject: [M3devel] Multiple executables from the same source In-Reply-To: References: <20130707021118.GA9726@topoi.pooq.com> Message-ID: <20130707155818.GB10466@topoi.pooq.com> On Sun, Jul 07, 2013 at 05:46:03AM +0000, Jay K wrote: > m3quake/cm3 is its own language, the declarations are actually > function calls, and the escape is the fairly general scripting > language. Most people just use the declarative stuff and don't break > out into the programming language. So you mean I should use something like if (test) implementation("Test") program("Test") else implementation("Main") program("Main") end in the m3makefile and run it with something like cm3 -Dtest Seems to work. Thanks. Now that I know what to look for, finding http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html made it relatively straightforward. -- hendrik From hendrik at topoi.pooq.com Sun Jul 7 18:39:17 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 7 Jul 2013 12:39:17 -0400 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <20130707155818.GB10466@topoi.pooq.com> References: <20130707021118.GA9726@topoi.pooq.com> <20130707155818.GB10466@topoi.pooq.com> Message-ID: <20130707163917.GA10814@topoi.pooq.com> On Sun, Jul 07, 2013 at 11:58:18AM -0400, Hendrik Boom wrote: > On Sun, Jul 07, 2013 at 05:46:03AM +0000, Jay K wrote: > > m3quake/cm3 is its own language, the declarations are actually > > function calls, and the escape is the fairly general scripting > > language. Most people just use the declarative stuff and don't break > > out into the programming language. > > So you mean I should use something like > > > if (test) correction: if defined("test") > implementation("Test") > program("Test") > else > implementation("Main") > program("Main") > end > > in the m3makefile > > and run it with something like > > cm3 -Dtest > > Seems to work. Thanks. Now that I know what to look for, finding > http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html made it > relatively straightforward. > > -- hendrik From hendrik at topoi.pooq.com Mon Jul 8 15:45:10 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 8 Jul 2013 09:45:10 -0400 Subject: [M3devel] I don't know what changed, or when, but thanks! Message-ID: <20130708134510.GA20805@topoi.pooq.com> Years ago, when a Modula 3 program failed because I called an absent method, it was difficult findig where the error was. But yesterday, I just ran the program in m3gdb and got a backtrace after failure. Of course the backtrace was full of apparent gibberish, but right in the middle is said: at ../src/runtime/common/RTException.m3:25 #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol table. ) at ../src/runtime/ex_frame/RTExFrame.m3:29 #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. ) at ../src/runtime/common/RTType.m3:850 #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in symbol table. ) at ../src/runtime/common/RTType.m3:834 #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol table. ) at ../src/Parse.m3:115 ---Type to continue, or q to quit--- #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol table. ) at ../src/Parse.m3:354 #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol table. ) at ../src/Main.m3:202 So it was quite clear I had to look at ../src/Parse.m3:115, and it was obvious where I had left our a shift := shift line in an OVERRIDES list. -- hendrik From rodney_bates at lcwb.coop Mon Jul 8 17:36:29 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 08 Jul 2013 10:36:29 -0500 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <20130708134510.GA20805@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> Message-ID: <51DADC7D.5060606@lcwb.coop> If you get m3gdb to realize this is modula-3 code, there will be a lot more useful info in the backtrace, like parameter values. Probably just doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. If you are using the head compiler and debugger, you will need very recent ones (perhaps in the last month?), as changes in the code generator created some regressions. All that I have seen are now fixed in the current head. On 07/08/2013 08:45 AM, Hendrik Boom wrote: > Years ago, when a Modula 3 program failed because I called an absent > method, it was difficult findig where the error was. > > But yesterday, I just ran the program in m3gdb and got a backtrace > after failure. > > Of course the backtrace was full of apparent gibberish, but right in > the middle is said: > > at ../src/runtime/common/RTException.m3:25 > #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol > table. > ) at ../src/runtime/ex_frame/RTExFrame.m3:29 > #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. > ) at ../src/runtime/common/RTType.m3:850 > #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in > symbol table. > ) > at ../src/runtime/common/RTType.m3:834 > #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol > table. > ) at ../src/Parse.m3:115 > ---Type to continue, or q to quit--- > #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol > table. > ) at ../src/Parse.m3:354 > #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol > table. > ) at ../src/Main.m3:202 > > > So it was quite clear I had to look at ../src/Parse.m3:115, and it was > obvious where I had left our a shift := shift line in an OVERRIDES > list. > > -- hendrik > > From rodney_bates at lcwb.coop Mon Jul 8 17:51:41 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 08 Jul 2013 10:51:41 -0500 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <20130707021118.GA9726@topoi.pooq.com> References: <20130707021118.GA9726@topoi.pooq.com> Message-ID: <51DAE00D.3090508@lcwb.coop> On 07/06/2013 09:11 PM, Hendrik Boom wrote: > I'm writiing and debugging a bunch of interfaces and modules. > They are all supposed to fit together into one happy executable. > > But of course, until I've finished debugging them > they fit together into one unhappy executable. > To test them properly I'd like to write a series of unit tests. > To run these tests I will need to make further executables, > each consisting of a test modules and several of the modules under test. > > Now with the usual structure of a Modula 3 workspace, > there is one m3makefile and a src directory, and it makes one executable, > not many, > and it doesn't really give me a choice of which executable I want. > > In the old days of C code and Makefiles, I could have multiple targets > each one being built with its own cc command > with its own list of source files names. > > Is there anything comparable for Modula 3? > > The best I've come up sith so far is to have a number of directories, > one for each test case, > with its own m3makefile and its own symbolic link to a common src directory. I have one project with three executables and a majority of the code shared. I am using essentially this scheme, but instead of the symlinks in the directories, I have 'include_dir("../common/src")' in the m3makefiles of the main programs. common/src has its m3makefile for all the stuff in common. This means means every main program has to independently compile all the common stuff and keep its own copies thereof. But disk is cheap and plentiful, and 200K..300K SLOC compiles from scratch fast enough. Someday, when bored, I plan to make the common stuff a separate library package. But then I will have to remember to recompile it when it changes, before compiling a main package. I have often thought about a second level of automatic, inter-package recompilation. It would have saved me some grief on occasions. But it could introduce new problems too. > > Is there something better? > > I'm not really interested in having all the test code > be part of the final application. > > For one thing, > I'd like to be able to test multiple implementations of a single interface, > such as a reference implementation and an efficient one, > so that I can compare the output and complain about the differences. > > -- hendrik > From hendrik at topoi.pooq.com Mon Jul 8 18:25:40 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 8 Jul 2013 12:25:40 -0400 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <51DAE00D.3090508@lcwb.coop> References: <20130707021118.GA9726@topoi.pooq.com> <51DAE00D.3090508@lcwb.coop> Message-ID: <20130708162540.GA22041@topoi.pooq.com> On Mon, Jul 08, 2013 at 10:51:41AM -0500, Rodney M. Bates wrote: > > > On 07/06/2013 09:11 PM, Hendrik Boom wrote: > >I'm writiing and debugging a bunch of interfaces and modules. > >They are all supposed to fit together into one happy executable. > > > >But of course, until I've finished debugging them > > they fit together into one unhappy executable. > >To test them properly I'd like to write a series of unit tests. > >To run these tests I will need to make further executables, > > each consisting of a test modules and several of the modules under test. > > > >Now with the usual structure of a Modula 3 workspace, > > there is one m3makefile and a src directory, and it makes one executable, > > not many, > > and it doesn't really give me a choice of which executable I want. > > > >In the old days of C code and Makefiles, I could have multiple targets > > each one being built with its own cc command > > with its own list of source files names. > > > >Is there anything comparable for Modula 3? > > > >The best I've come up sith so far is to have a number of directories, > > one for each test case, > > with its own m3makefile and its own symbolic link to a common src directory. > > I have one project with three executables and a majority of the code shared. I > am using essentially this scheme, but instead of the symlinks in the directories, > I have 'include_dir("../common/src")' in the m3makefiles of the main programs. > common/src has its m3makefile for all the stuff in common. Is this a way of getting cm3 to search ../common/src as sell as the src it usually looks through? That may be what I wanted ... but IF statements in m3makefiles suffice for now. It's useful to know that include_dir is available, though. Is there any advice how to make sure the variable names I use in an m3makefiles don't confllict with the ones that cm3 might be using to manage the compilation? > > This means means every main program has to independently compile all the common > stuff and keep its own copies thereof. But disk is cheap and plentiful, > and 200K..300K SLOC compiles from scratch fast enough. Independently compiling all that stuff is what I originally wanted -- it would give me the option of trying independent and very different implementations for some interfaces so as to discover hidden logical dependencies. And the extra disk space is not that much space -- considering that it only needs to be tied up during testing, -- hendrik From hendrik at topoi.pooq.com Mon Jul 8 18:30:38 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 8 Jul 2013 12:30:38 -0400 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <51DADC7D.5060606@lcwb.coop> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> Message-ID: <20130708163038.GB22041@topoi.pooq.com> On Mon, Jul 08, 2013 at 10:36:29AM -0500, Rodney M. Bates wrote: > If you get m3gdb to realize this is modula-3 code, there will be a lot > more useful info in the backtrace, like parameter values. Probably just > doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. Yes, that would probably help. > > If you are using the head compiler and debugger, you will need very > recent ones (perhaps in the last month?), as changes in the code > generator created some regressions. All that I have seen are now > fixed in the current head. Time to upgrade, then. Please understand, I was being genuinely happy, not complaining in a sarcastic way. Knowing just where I called into deep space was a huge time-saver. -- hendrik > > On 07/08/2013 08:45 AM, Hendrik Boom wrote: > >Years ago, when a Modula 3 program failed because I called an absent > >method, it was difficult findig where the error was. > > > >But yesterday, I just ran the program in m3gdb and got a backtrace > >after failure. > > > >Of course the backtrace was full of apparent gibberish, but right in > >the middle is said: > > > > at ../src/runtime/common/RTException.m3:25 > >#14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol > >table. > >) at ../src/runtime/ex_frame/RTExFrame.m3:29 > >#15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. > >) at ../src/runtime/common/RTType.m3:850 > >#16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in > >symbol table. > >) > > at ../src/runtime/common/RTType.m3:834 > >#17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol > >table. > >) at ../src/Parse.m3:115 > >---Type to continue, or q to quit--- > >#18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol > >table. > >) at ../src/Parse.m3:354 > >#19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol > >table. > >) at ../src/Main.m3:202 > > > > > >So it was quite clear I had to look at ../src/Parse.m3:115, and it was > >obvious where I had left our a shift := shift line in an OVERRIDES > >list. > > > >-- hendrik > > > > > From rodney_bates at lcwb.coop Mon Jul 8 20:20:05 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 08 Jul 2013 13:20:05 -0500 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <20130708163038.GB22041@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> Message-ID: <51DB02D5.8070209@lcwb.coop> On 07/08/2013 11:30 AM, Hendrik Boom wrote: > On Mon, Jul 08, 2013 at 10:36:29AM -0500, Rodney M. Bates wrote: >> If you get m3gdb to realize this is modula-3 code, there will be a lot >> more useful info in the backtrace, like parameter values. Probably just >> doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. > > Yes, that would probably help. >> >> If you are using the head compiler and debugger, you will need very >> recent ones (perhaps in the last month?), as changes in the code >> generator created some regressions. All that I have seen are now >> fixed in the current head. > > Time to upgrade, then. > > Please understand, I was being genuinely happy, not complaining in a > sarcastic way. Yes, I read it that way, but I can sometimes get confused about that. BTW, you can also catch exception that is later handled, at the point where it is raised, by setting (in advance) a breakpoint in a place like Raise in the RTS. You could get lots of false hits this way though, if raise-handle of other exceptions is something that is happening routinely. > > Knowing just where I called into deep space was a huge time-saver. > > -- hendrik > >> >> On 07/08/2013 08:45 AM, Hendrik Boom wrote: >>> Years ago, when a Modula 3 program failed because I called an absent >>> method, it was difficult findig where the error was. >>> >>> But yesterday, I just ran the program in m3gdb and got a backtrace >>> after failure. >>> >>> Of course the backtrace was full of apparent gibberish, but right in >>> the middle is said: >>> >>> at ../src/runtime/common/RTException.m3:25 >>> #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol >>> table. >>> ) at ../src/runtime/ex_frame/RTExFrame.m3:29 >>> #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. >>> ) at ../src/runtime/common/RTType.m3:850 >>> #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in >>> symbol table. >>> ) >>> at ../src/runtime/common/RTType.m3:834 >>> #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol >>> table. >>> ) at ../src/Parse.m3:115 >>> ---Type to continue, or q to quit--- >>> #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol >>> table. >>> ) at ../src/Parse.m3:354 >>> #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol >>> table. >>> ) at ../src/Main.m3:202 >>> >>> >>> So it was quite clear I had to look at ../src/Parse.m3:115, and it was >>> obvious where I had left our a shift := shift line in an OVERRIDES >>> list. >>> >>> -- hendrik >>> >>> >> > From rodney_bates at lcwb.coop Mon Jul 8 20:13:16 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 08 Jul 2013 13:13:16 -0500 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <20130708162540.GA22041@topoi.pooq.com> References: <20130707021118.GA9726@topoi.pooq.com> <51DAE00D.3090508@lcwb.coop> <20130708162540.GA22041@topoi.pooq.com> Message-ID: <51DB013C.6030200@lcwb.coop> On 07/08/2013 11:25 AM, Hendrik Boom wrote: > On Mon, Jul 08, 2013 at 10:51:41AM -0500, Rodney M. Bates wrote: >> >> >> On 07/06/2013 09:11 PM, Hendrik Boom wrote: >>> I'm writiing and debugging a bunch of interfaces and modules. >>> They are all supposed to fit together into one happy executable. >>> >>> But of course, until I've finished debugging them >>> they fit together into one unhappy executable. >>> To test them properly I'd like to write a series of unit tests. >>> To run these tests I will need to make further executables, >>> each consisting of a test modules and several of the modules under test. >>> >>> Now with the usual structure of a Modula 3 workspace, >>> there is one m3makefile and a src directory, and it makes one executable, >>> not many, >>> and it doesn't really give me a choice of which executable I want. >>> >>> In the old days of C code and Makefiles, I could have multiple targets >>> each one being built with its own cc command >>> with its own list of source files names. >>> >>> Is there anything comparable for Modula 3? >>> >>> The best I've come up sith so far is to have a number of directories, >>> one for each test case, >>> with its own m3makefile and its own symbolic link to a common src directory. >> >> I have one project with three executables and a majority of the code shared. I >> am using essentially this scheme, but instead of the symlinks in the directories, >> I have 'include_dir("../common/src")' in the m3makefiles of the main programs. >> common/src has its m3makefile for all the stuff in common. > > Is this a way of getting cm3 to search ../common/src as sell as the src > it usually looks through? Yes,, it uses ../common/src/m3makefile and whatever it refers to. I don't know the precise semantics, but I imagine it just interprets the contents of the included m3makefile in place of the include_dir. > > That may be what I wanted ... but IF statements in m3makefiles suffice > for now. > > It's useful to know that include_dir is available, though. > > Is there any advice how to make sure the variable names I use in an > m3makefiles don't confllict with the ones that cm3 might be using to > manage the compilation? > I don't think there is anything graceful here, other than try it and see if things blow up. >> >> This means means every main program has to independently compile all the common >> stuff and keep its own copies thereof. But disk is cheap and plentiful, >> and 200K..300K SLOC compiles from scratch fast enough. > > Independently compiling all that stuff is what I originally wanted -- > it would give me the option of trying independent and very different > implementations for some interfaces so as to discover hidden logical > dependencies. > > And the extra disk space is not that much space -- considering that > it only needs to be tied up during testing, > > -- hendrik > From hendrik at topoi.pooq.com Mon Jul 8 22:25:39 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 8 Jul 2013 16:25:39 -0400 Subject: [M3devel] typo in http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html Message-ID: <20130708202539.GA30241@topoi.pooq.com> The paragraph in section 9.8 that defines 'defined' has a typo: evaluated before begin passed to defined. instead of evaluated before being passed to defined. -- hendrik From mika at async.caltech.edu Thu Jul 11 11:08:04 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Thu, 11 Jul 2013 02:08:04 -0700 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <51DADC7D.5060606@lcwb.coop> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> Message-ID: <20130711090804.939171A207D@async.async.caltech.edu> This is just a pet peeve of mine, but I never remember to capitalize "Modula-3" right. There is no way to make m3gdb also recognize set lang m3 set lang modula3 set lang modula-3 set lang m0dulaIII etc...? "Rodney M. Bates" writes: >If you get m3gdb to realize this is modula-3 code, there will be a lot >more useful info in the backtrace, like parameter values. Probably just >doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. > >If you are using the head compiler and debugger, you will need very >recent ones (perhaps in the last month?), as changes in the code >generator created some regressions. All that I have seen are now >fixed in the current head. > >On 07/08/2013 08:45 AM, Hendrik Boom wrote: >> Years ago, when a Modula 3 program failed because I called an absent >> method, it was difficult findig where the error was. >> >> But yesterday, I just ran the program in m3gdb and got a backtrace >> after failure. >> >> Of course the backtrace was full of apparent gibberish, but right in >> the middle is said: >> >> at ../src/runtime/common/RTException.m3:25 >> #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol >> table. >> ) at ../src/runtime/ex_frame/RTExFrame.m3:29 >> #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. >> ) at ../src/runtime/common/RTType.m3:850 >> #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in >> symbol table. >> ) >> at ../src/runtime/common/RTType.m3:834 >> #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol >> table. >> ) at ../src/Parse.m3:115 >> ---Type to continue, or q to quit--- >> #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol >> table. >> ) at ../src/Parse.m3:354 >> #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol >> table. >> ) at ../src/Main.m3:202 >> >> >> So it was quite clear I had to look at ../src/Parse.m3:115, and it was >> obvious where I had left our a shift := shift line in an OVERRIDES >> list. >> >> -- hendrik >> >> From wagner at elego.de Thu Jul 11 11:20:18 2013 From: wagner at elego.de (Olaf Wagner) Date: Thu, 11 Jul 2013 11:20:18 +0200 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <20130711090804.939171A207D@async.async.caltech.edu> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130711090804.939171A207D@async.async.caltech.edu> Message-ID: <20130711112018.3bf3ba6f.wagner@elego.de> On Thu, 11 Jul 2013 02:08:04 -0700 mika at async.caltech.edu wrote: > This is just a pet peeve of mine, but I never remember to capitalize "Modula-3" right. > There is no way to make m3gdb also recognize > > set lang m3 +1 > set lang modula3 > set lang modula-3 > set lang m0dulaIII -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 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 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Thu Jul 11 17:56:35 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Thu, 11 Jul 2013 08:56:35 -0700 Subject: [M3devel] netobj bug report In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF2F168037@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF2F168037@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <20130711155635.869211A207D@async.async.caltech.edu> The code in CM3 is the same. I am 95% certain this is a bug. The logic just doesn't make sense. All you should have to do to reproduce it is the following: instantiate a subtype of NetObj.T without exporting it. Then try to Pickle it. Your program I think will crash (for no good reason). Your program I think will not crash if you do export it. The logic is checking for a surrogate and crashing if you attempt to pickle one: > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; The problem is that x.r is only non-NIL once you export the object. For a new object that has not been exported, x.r is NIL. Therefore it is of type Transport.Location and appears to be a surrogate, even though it is not a surrogate. The test should be IF x.r = NIL OR NOT ISTYPE... Mika "Coleburn, Randy" writes: >Hi Mika: > >I'm deep in the middle of some other stuff, but read your post with interes= >t because I've done a LOT of work with both Pickles and Network Objects. > >On the surface, I'm not sure whether this is a bug or not. I've never enco= >untered this problem before. But, my brain is in left-field right now with= > all else I have going on. > >I know that I always used the Pickle2 (2nd generation of pickles) to get ar= >ound some problems with the first generation. I never used PM3, just CM3 a= >nd the original "SRC-Systems Research Center" versions. > >I know you can also write and register special "pickler" procedures for any= > particular object to get around problems with the default pickling procedu= >res (read/write). I've had to do this on occasion both to resolve problems= > and to increase performance. I can provide examples if you need them. > >--Randy > >Randy C. Coleburn, CISSP-ISSEP, GCED >Corporate Information Security Officer (CISO) >Scientific Research Corporation > >-----Original Message----- >From: mika at async.caltech.edu [mailto:mika at async.caltech.edu]=20 >Sent: Thursday, June 27, 2013 7:01 PM >To: m3devel at elegosoft.com >Subject: EXT:[M3devel] netobj bug report > >Hi m3devel, > >I think I found a bug in the Network Objects code. > >Here is what I was doing: I made an object that I wanted to export using Ne= >twork Objects, but I *also* wanted to Pickle the object locally (for persis= >tence). > >I find that if I create the object and try to pickle it, I get a Pickle err= >or "Can't pickle a surrogate object". =20 > >The source of the error is in StubLib.m3, the Pickle special that is record= >ed for network objects: > >PROCEDURE OutSpecial(self: Pickle.Special; > r: REFANY; > writer: Pickle.Writer) > RAISES {Pickle.Error, Wr.Failure, Thread.Alerted} =3D > BEGIN > TYPECASE writer OF > | SpecWr(wtr) =3D> OutRef(wtr.c, r); > ELSE > TYPECASE r OF > | NetObj.T(x) =3D> > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; > ELSE RAISE Pickle.Error("Can't Pickle Rd.T or Wr.T"); > END; > END; > END OutSpecial; > >(In CM3, OutSpecial2 has the same bug for Pickle2 pickles. PM3 doesn't hav= >e Pickle2 nor OutSpecial2.) > >The problem is the test > > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; > >The intent, I think, is that an object that is remote (that is, has x.r of = >type Transport.Location) should not be pickle-able. > >The problem is that x.r is initially NIL, and NIL is a member of Transport.= >Location. > >My workaround is to FIRST export the object before attempting to Pickle it.= > This works fine but it shouldn't be necessary, should it? What if I don'= >t want to export the object, but just pickle it? > >I believe the test should be changed to be > >IF x.r =3D NIL OR NOT ISTYPE(x.r, Transport.Location) THEN... > > Mika > From rodney_bates at lcwb.coop Thu Jul 11 22:07:23 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 11 Jul 2013 15:07:23 -0500 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <20130711090804.939171A207D@async.async.caltech.edu> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130711090804.939171A207D@async.async.caltech.edu> Message-ID: <51DF107B.9020600@lcwb.coop> On 07/11/2013 04:08 AM, mika at async.caltech.edu wrote: > This is just a pet peeve of mine, but I never remember to capitalize "Modula-3" right. > There is no way to make m3gdb also recognize > > set lang m3 > set lang modula3 > set lang modula-3 > set lang m0dulaIII Hmm,, I thought I had implemented recognition of several variants. From: modula3.elegosoft.com/cm3/doc/help/m3gdb/m3gdb-onepage.html#id372899 "In case you have trouble remembering which spelling of the language name to use, it accepts the cartesian product of "Modula" spelled out or abbreviated with a single "M", lowercase/uppercase "M", and with/without the hyphen." But this is for the "info Modula-3 command, not "set lang Modula-3". I'll add that to my list. I may not do the arbitrary mixed case, nor the Roman numeral, though, just yet :-). > > etc...? > > "Rodney M. Bates" writes: >> If you get m3gdb to realize this is modula-3 code, there will be a lot >> more useful info in the backtrace, like parameter values. Probably just >> doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. >> >> If you are using the head compiler and debugger, you will need very >> recent ones (perhaps in the last month?), as changes in the code >> generator created some regressions. All that I have seen are now >> fixed in the current head. >> >> On 07/08/2013 08:45 AM, Hendrik Boom wrote: >>> Years ago, when a Modula 3 program failed because I called an absent >>> method, it was difficult findig where the error was. >>> >>> But yesterday, I just ran the program in m3gdb and got a backtrace >>> after failure. >>> >>> Of course the backtrace was full of apparent gibberish, but right in >>> the middle is said: >>> >>> at ../src/runtime/common/RTException.m3:25 >>> #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol >>> table. >>> ) at ../src/runtime/ex_frame/RTExFrame.m3:29 >>> #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. >>> ) at ../src/runtime/common/RTType.m3:850 >>> #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in >>> symbol table. >>> ) >>> at ../src/runtime/common/RTType.m3:834 >>> #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol >>> table. >>> ) at ../src/Parse.m3:115 >>> ---Type to continue, or q to quit--- >>> #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol >>> table. >>> ) at ../src/Parse.m3:354 >>> #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol >>> table. >>> ) at ../src/Main.m3:202 >>> >>> >>> So it was quite clear I had to look at ../src/Parse.m3:115, and it was >>> obvious where I had left our a shift := shift line in an OVERRIDES >>> list. >>> >>> -- hendrik >>> >>> > From hendrik at topoi.pooq.com Mon Jul 15 18:59:53 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 15 Jul 2013 12:59:53 -0400 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130708163038.GB22041@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> Message-ID: <20130715165952.GA6645@topoi.pooq.com> On Mon, Jul 08, 2013 at 12:30:38PM -0400, Hendrik Boom wrote: > On Mon, Jul 08, 2013 at 10:36:29AM -0500, Rodney M. Bates wrote: > > If you get m3gdb to realize this is modula-3 code, there will be a lot > > more useful info in the backtrace, like parameter values. Probably just > > doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. > > Yes, that would probably help. > > > > If you are using the head compiler and debugger, you will need very > > recent ones (perhaps in the last month?), as changes in the code > > generator created some regressions. All that I have seen are now > > fixed in the current head. > > Time to upgrade, then. I'm currently running version 5.8.6, which identifies itself as last updated on 2010-04-11. Is that still the latest release? I haven't found a newer. Does it come ddown to checking out current source from cvs and using my existing Modula 3 to compile it? And does cvsup work again? -- hendrik From rodney_bates at lcwb.coop Mon Jul 15 19:43:17 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 15 Jul 2013 12:43:17 -0500 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130715165952.GA6645@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> Message-ID: <51E434B5.3000706@lcwb.coop> On 07/15/2013 11:59 AM, Hendrik Boom wrote: > On Mon, Jul 08, 2013 at 12:30:38PM -0400, Hendrik Boom wrote: >> On Mon, Jul 08, 2013 at 10:36:29AM -0500, Rodney M. Bates wrote: >>> If you get m3gdb to realize this is modula-3 code, there will be a lot >>> more useful info in the backtrace, like parameter values. Probably just >>> doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. >> >> Yes, that would probably help. >>> >>> If you are using the head compiler and debugger, you will need very >>> recent ones (perhaps in the last month?), as changes in the code >>> generator created some regressions. All that I have seen are now >>> fixed in the current head. >> >> Time to upgrade, then. > > I'm currently running version 5.8.6, which identifies itself as last > updated on 2010-04-11. Is that still the latest release? I haven't > found a newer. I think that is the latest release, or maybe the slightly updated cvs release branch. > > Does it come ddown to checking out current source from cvs and using > my existing Modula 3 to compile it? > If you are using or want to use the head version, yes. If you are using the release compiler and debugger, I think most or all of the regressions I referred to have happened since the release, so using that compiler may give you pretty much all m3gdb function as exists. I don't remember adding much new function in a while. It is possible however, to get the latest m3gdb from cvs head and compile and use it along with any of various older compilers and libraries, even PM3, EZM3, or, (gasp,) SRC M3. I always try to make m3gdb remain compatible with all the older compilers, whenever I add anything. > And does cvsup work again? I don't know about this. > > -- hendrik > From hendrik at topoi.pooq.com Thu Jul 18 19:14:56 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 18 Jul 2013 13:14:56 -0400 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <51E434B5.3000706@lcwb.coop> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> <51E434B5.3000706@lcwb.coop> Message-ID: <20130718171455.GA2631@topoi.pooq.com> On Mon, Jul 15, 2013 at 12:43:17PM -0500, Rodney M. Bates wrote: > > If you are using the release compiler and debugger, I think most or > all of the regressions I referred to have happened since the release, > so using that compiler may give you pretty much all m3gdb function > as exists. I don't remember adding much new function in a while. Just to be clear, by "the regressions since the release" do you mean problems that have appeaared since the release, or problems that have been fixed since the releases. > > It is possible however, to get the latest m3gdb from cvs head and compile > and use it along with any of various older compilers and libraries, > even PM3, EZM3, or, (gasp,) SRC M3. I always try to make m3gdb remain > compatible with all the older compilers, whenever I add anything. I have to say, still maintaining compatibility with SRC M3 is amazing. -- hendrik From dragisha at m3w.org Sun Jul 21 15:33:12 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Jul 2013 15:33:12 +0200 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130718171455.GA2631@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> <51E434B5.3000706@lcwb.coop> <20130718171455.GA2631@topoi.pooq.com> Message-ID: It's problems that have appeared, by definition of regression. -- Dragi?a Duri? dragisha at m3w.org On Jul 18, 2013, at 7:14 PM, Hendrik Boom wrote: > Just to be clear, by "the regressions since the release" do you mean > problems that have appeaared since the release, or problems that have > been fixed since the > releases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Jul 21 17:46:44 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Jul 2013 10:46:44 -0500 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130718171455.GA2631@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> <51E434B5.3000706@lcwb.coop> <20130718171455.GA2631@topoi.pooq.com> Message-ID: <51EC0264.600@lcwb.coop> On 07/18/2013 12:14 PM, Hendrik Boom wrote: > On Mon, Jul 15, 2013 at 12:43:17PM -0500, Rodney M. Bates wrote: >> >> If you are using the release compiler and debugger, I think most or >> all of the regressions I referred to have happened since the release, >> so using that compiler may give you pretty much all m3gdb function >> as exists. I don't remember adding much new function in a while. > > Just to be clear, by "the regressions since the release" do you mean > problems that have appeaared since the release, or problems that have > been fixed since the > releases. > Yes, I meant regressions that first appeared since the release. Not that there aren't heaps of bugs in m3gdb and its gcc-backend support, in the release and the head. I have probably a couple of dozen handwritten sheets with to-do notes for m3gdb. But there is a lot that does work. >> >> It is possible however, to get the latest m3gdb from cvs head and compile >> and use it along with any of various older compilers and libraries, >> even PM3, EZM3, or, (gasp,) SRC M3. I always try to make m3gdb remain >> compatible with all the older compilers, whenever I add anything. > > I have to say, still maintaining compatibility with SRC M3 is amazing. > > -- hendrik > From rodney_bates at lcwb.coop Sun Jul 21 17:52:22 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Jul 2013 10:52:22 -0500 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130718171455.GA2631@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> <51E434B5.3000706@lcwb.coop> <20130718171455.GA2631@topoi.pooq.com> Message-ID: <51EC03B6.80103@lcwb.coop> On 07/18/2013 12:14 PM, Hendrik Boom wrote: > On Mon, Jul 15, 2013 at 12:43:17PM -0500, Rodney M. Bates wrote: >> >> If you are using the release compiler and debugger, I think most or >> all of the regressions I referred to have happened since the release, >> so using that compiler may give you pretty much all m3gdb function >> as exists. I don't remember adding much new function in a while. > > Just to be clear, by "the regressions since the release" do you mean > problems that have appeaared since the release, or problems that have > been fixed since the > releases. > >> >> It is possible however, to get the latest m3gdb from cvs head and compile >> and use it along with any of various older compilers and libraries, >> even PM3, EZM3, or, (gasp,) SRC M3. I always try to make m3gdb remain >> compatible with all the older compilers, whenever I add anything. > > I have to say, still maintaining compatibility with SRC M3 is amazing. Well, thank you. Actually, it's mostly just work and intention. Whenever some compiler change alters the runtime organization or the debug info, I don't strip out or modify what's there, I just add new alternative code and some detection of which to use. In a few places, it is difficult or impossible to distinguish something. A totally reworked debug info system, probably dwarf, would be refreshing, but it's a big job and there are priorities. > > -- hendrik > From rodney_bates at lcwb.coop Wed Jul 24 16:10:31 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Jul 2013 09:10:31 -0500 Subject: [M3devel] Pickles, TextLiterals, and word size Message-ID: <51EFE057.4030301@lcwb.coop> There is what I would call a bug in TextLiteral.i3 whose effect is that a TextLiteral.T has a different fingerprint on 32- and 64-bit machines. So you can't pickle a Text literal on one word-sized machine and unpickle it on the other. But fixing this will have the effect of invalidating any existing pickles written on a 64-bit machine before the fix, so they can't be read after the fix, even on a 64-bit machine. They would have to be rewritten after the fix. Is anybody doing the latter? Would having to recreate your pickles be a problem? Apparently, nobody is going cross-word-size, or we'd have heard about it. I would like to fix it properly, but don't want to undermine anybody's working system. From hendrik at topoi.pooq.com Wed Jul 24 17:34:47 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 24 Jul 2013 11:34:47 -0400 Subject: [M3devel] Pickles, TextLiterals, and word size In-Reply-To: <51EFE057.4030301@lcwb.coop> References: <51EFE057.4030301@lcwb.coop> Message-ID: <20130724153447.GA12587@topoi.pooq.com> On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote: > There is what I would call a bug in TextLiteral.i3 whose effect is that a > TextLiteral.T has a different fingerprint on 32- and 64-bit machines. > So you can't pickle a Text literal on one word-sized machine and unpickle > it on the other. > > But fixing this will have the effect of invalidating any existing pickles > written on a 64-bit machine before the fix, so they can't be read after > the fix, even on a 64-bit machine. They would have to be rewritten after > the fix. Ah! The problems of long-term compatibility! Is there any way of looking at a a pickle and determining whether it comes from a 32- of 64- bit machine? It there a way of special-casing the specific fingerprint that's about to be invalidated, so as to convert it properly on input only, while generating the new one on output? > > Is anybody doing the latter? Would having to recreate your pickles be a > problem? Apparently, nobody is going cross-word-size, or we'd have heard > about it. > > I would like to fix it properly, but don't want to undermine anybody's > working system. > From rcolebur at SCIRES.COM Wed Jul 24 19:03:12 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 24 Jul 2013 17:03:12 +0000 Subject: [M3devel] Pickles, TextLiterals, and word size In-Reply-To: <20130724153447.GA12587@topoi.pooq.com> References: <51EFE057.4030301@lcwb.coop>, <20130724153447.GA12587@topoi.pooq.com> Message-ID: <2CE8061F-4DF0-4645-AADB-F1582EDEDD73@SCIRES.COM> Hendrik raises some good questions. It would be great if "the fix" could be implemented in a way that either self-corrects for any pickles written prior to "the fix", or at least presents a run-time notification of a problem, but if this can't be done, I vote to go ahead with "the fix" and we will deal with it on a case-by-case basis. I've written a fair amount of stuff that uses pickles to persist object data on secondary storage, so I will have to deal with that, but I think it is more important this problem gets solved. Thanks, Randy Coleburn Sent from my iPad On Jul 24, 2013, at 11:34 AM, "Hendrik Boom" wrote: > On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote: >> There is what I would call a bug in TextLiteral.i3 whose effect is that a >> TextLiteral.T has a different fingerprint on 32- and 64-bit machines. >> So you can't pickle a Text literal on one word-sized machine and unpickle >> it on the other. >> >> But fixing this will have the effect of invalidating any existing pickles >> written on a 64-bit machine before the fix, so they can't be read after >> the fix, even on a 64-bit machine. They would have to be rewritten after >> the fix. > > Ah! The problems of long-term compatibility! > > Is there any way of looking at a a pickle and determining whether it > comes from a 32- of 64- bit machine? > > It there a way of special-casing the specific fingerprint that's about > to be invalidated, so as to convert it properly on input only, while > generating the new one on output? > >> >> Is anybody doing the latter? Would having to recreate your pickles be a >> problem? Apparently, nobody is going cross-word-size, or we'd have heard >> about it. >> >> I would like to fix it properly, but don't want to undermine anybody's >> working system. >> From rodney_bates at lcwb.coop Wed Jul 24 19:14:39 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Jul 2013 12:14:39 -0500 Subject: [M3devel] Pickles, TextLiterals, and word size In-Reply-To: <20130724153447.GA12587@topoi.pooq.com> References: <51EFE057.4030301@lcwb.coop> <20130724153447.GA12587@topoi.pooq.com> Message-ID: <51F00B7F.9020705@lcwb.coop> On 07/24/2013 10:34 AM, Hendrik Boom wrote: > On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote: >> There is what I would call a bug in TextLiteral.i3 whose effect is that a >> TextLiteral.T has a different fingerprint on 32- and 64-bit machines. >> So you can't pickle a Text literal on one word-sized machine and unpickle >> it on the other. >> >> But fixing this will have the effect of invalidating any existing pickles >> written on a 64-bit machine before the fix, so they can't be read after >> the fix, even on a 64-bit machine. They would have to be rewritten after >> the fix. > > Ah! The problems of long-term compatibility! > > Is there any way of looking at a a pickle and determining whether it > comes from a 32- of 64- bit machine? Yes, the pickle contains word size, LONGINT/LONGCARD size, floating point representation, endianness, lazy alignment, maximum alignment, record alignment, and now, widechar size, all for the system it was written on. > > It there a way of special-casing the specific fingerprint that's about > to be invalidated, so as to convert it properly on input only, while > generating the new one on output? > Yes, I thought about this. It would not be hard to find out what the two fingerprints are and test one read from a pickle against these values. But the problem is, there is an unbounded set of types that would depend indirectly on this, and they can't all be accounted for. Using, e.g., BITSIZE(INTEGER) as a bound in a range is the way this is happening it the subject case. Hmm, maybe I could just do the specific derived fingerprints for a TextLiteral.T, and that would be good enough. Let the programmer be responsible for other types. I think it would fix the immediate problem without undermining anything existing. I already have file dumps I can dig the values out of. I'll look into that. Thanks! >> >> Is anybody doing the latter? Would having to recreate your pickles be a >> problem? Apparently, nobody is going cross-word-size, or we'd have heard >> about it. >> >> I would like to fix it properly, but don't want to undermine anybody's >> working system. >> > From rodney_bates at lcwb.coop Wed Jul 24 22:59:12 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Jul 2013 15:59:12 -0500 Subject: [M3devel] Pickles, TextLiterals, and word size In-Reply-To: <51F00B7F.9020705@lcwb.coop> References: <51EFE057.4030301@lcwb.coop> <20130724153447.GA12587@topoi.pooq.com> <51F00B7F.9020705@lcwb.coop> Message-ID: <51F04020.1070200@lcwb.coop> On 07/24/2013 12:14 PM, Rodney M. Bates wrote: > > > On 07/24/2013 10:34 AM, Hendrik Boom wrote: >> On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote: >>> There is what I would call a bug in TextLiteral.i3 whose effect is that a >>> TextLiteral.T has a different fingerprint on 32- and 64-bit machines. >>> So you can't pickle a Text literal on one word-sized machine and unpickle >>> it on the other. >>> >>> But fixing this will have the effect of invalidating any existing pickles >>> written on a 64-bit machine before the fix, so they can't be read after >>> the fix, even on a 64-bit machine. They would have to be rewritten after >>> the fix. >> >> Ah! The problems of long-term compatibility! >> >> Is there any way of looking at a a pickle and determining whether it >> comes from a 32- of 64- bit machine? > > Yes, the pickle contains word size, LONGINT/LONGCARD size, floating > point representation, endianness, lazy alignment, maximum alignment, > record alignment, and now, widechar size, all for the system it was > written on. > > >> >> It there a way of special-casing the specific fingerprint that's about >> to be invalidated, so as to convert it properly on input only, while >> generating the new one on output? >> > > Yes, I thought about this. It would not be hard to find out what the > two fingerprints are and test one read from a pickle against these values. > > But the problem is, there is an unbounded set of types that would depend > indirectly on this, and they can't all be accounted for. Using, e.g., > BITSIZE(INTEGER) as a bound in a range is the way this is happening > it the subject case. > > Hmm, maybe I could just do the specific derived fingerprints for a > TextLiteral.T, and that would be good enough. Let the programmer be > responsible for other types. I think it would fix the immediate > problem without undermining anything existing. No, that won't work either. That would only fix the case where the TextLiteral is the top-level, and thus only, "object" in a pickle. Not very likely. When the TextLiteral is a field/element of some containing object, it is the topmost object in the entire pickle whose fingerprint is used to find the type in the reading program. Actually, pickling a TextLiteral might not be very common at all. > > I already have file dumps I can dig the values out of. I'll look > into that. Thanks! > > >>> >>> Is anybody doing the latter? Would having to recreate your pickles be a >>> problem? Apparently, nobody is going cross-word-size, or we'd have heard >>> about it. >>> >>> I would like to fix it properly, but don't want to undermine anybody's >>> working system. >>> >> > > From mika at async.caltech.edu Sat Jul 27 05:07:17 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 26 Jul 2013 20:07:17 -0700 Subject: [M3devel] netobj bug report In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF2F168037@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF2F168037@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <20130727030717.095FD1A208C@async.async.caltech.edu> Hi Randy (or anyone on m3devel), Have you considered my bug report? Can someone who knows the code better than me analyze the situation and either clear my code or justify the existing code as checked in and tell me what I'm doing wrong? I have had to change the code as I described in my old pm3 sources to get my application working, tired of doing workarounds. I strongly suspect we're dealing with an annoying bug, and it looks present in both Pickle.m3 and Pickle2.m3, all versions (CM3, PM3 at least). Mika "Coleburn, Randy" writes: >Hi Mika: > >I'm deep in the middle of some other stuff, but read your post with interes= >t because I've done a LOT of work with both Pickles and Network Objects. > >On the surface, I'm not sure whether this is a bug or not. I've never enco= >untered this problem before. But, my brain is in left-field right now with= > all else I have going on. > >I know that I always used the Pickle2 (2nd generation of pickles) to get ar= >ound some problems with the first generation. I never used PM3, just CM3 a= >nd the original "SRC-Systems Research Center" versions. > >I know you can also write and register special "pickler" procedures for any= > particular object to get around problems with the default pickling procedu= >res (read/write). I've had to do this on occasion both to resolve problems= > and to increase performance. I can provide examples if you need them. > >--Randy > >Randy C. Coleburn, CISSP-ISSEP, GCED >Corporate Information Security Officer (CISO) >Scientific Research Corporation > >-----Original Message----- >From: mika at async.caltech.edu [mailto:mika at async.caltech.edu]=20 >Sent: Thursday, June 27, 2013 7:01 PM >To: m3devel at elegosoft.com >Subject: EXT:[M3devel] netobj bug report > >Hi m3devel, > >I think I found a bug in the Network Objects code. > >Here is what I was doing: I made an object that I wanted to export using Ne= >twork Objects, but I *also* wanted to Pickle the object locally (for persis= >tence). > >I find that if I create the object and try to pickle it, I get a Pickle err= >or "Can't pickle a surrogate object". =20 > >The source of the error is in StubLib.m3, the Pickle special that is record= >ed for network objects: > >PROCEDURE OutSpecial(self: Pickle.Special; > r: REFANY; > writer: Pickle.Writer) > RAISES {Pickle.Error, Wr.Failure, Thread.Alerted} =3D > BEGIN > TYPECASE writer OF > | SpecWr(wtr) =3D> OutRef(wtr.c, r); > ELSE > TYPECASE r OF > | NetObj.T(x) =3D> > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; > ELSE RAISE Pickle.Error("Can't Pickle Rd.T or Wr.T"); > END; > END; > END OutSpecial; > >(In CM3, OutSpecial2 has the same bug for Pickle2 pickles. PM3 doesn't hav= >e Pickle2 nor OutSpecial2.) > >The problem is the test > > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; > >The intent, I think, is that an object that is remote (that is, has x.r of = >type Transport.Location) should not be pickle-able. > >The problem is that x.r is initially NIL, and NIL is a member of Transport.= >Location. > >My workaround is to FIRST export the object before attempting to Pickle it.= > This works fine but it shouldn't be necessary, should it? What if I don'= >t want to export the object, but just pickle it? > >I believe the test should be changed to be > >IF x.r =3D NIL OR NOT ISTYPE(x.r, Transport.Location) THEN... > > Mika > From rodney_bates at lcwb.coop Tue Jul 2 00:40:41 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 01 Jul 2013 17:40:41 -0500 Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? Message-ID: <51D20569.1010600@lcwb.coop> After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll total 792 -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp where parse.c is changed. When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l total 1944 -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c ../../gcc-4.7/gcc/m3cg/parse.c But parse.o has not changed (I can verify this by running gdb on cm3cg), and: rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll total 792 -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp My edits to parse.c have been undone! If I recreate the edited parse.c, then chmod 444 parse.c and recompile, it has no effect. parse.c still gets changed back to the unedited version. Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory (I have no idea how long this has been the case), and I have not been able to get cvs to admit to having any awareness of this directory or anything in it, using cvs log, cvs update or cvs checkout. I even tried manually creating a CVS subdirectory, but without getting cvs to tell me something about its current version number of parse.c, I can't create a line in CVS/Entries for it, and cvs continues to claim total ignorance of this file. What is going on here? Is parse.c (and all of m3cg) being automatically created? From where? cvs update -P does not remove m3cg, BTW. From jay.krell at cornell.edu Tue Jul 2 03:48:00 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 2 Jul 2013 01:48:00 +0000 Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? In-Reply-To: <51D20569.1010600@lcwb.coop> References: <51D20569.1010600@lcwb.coop> Message-ID: There is one parse.c for several gcc forks. It is copied or linked by m3makefile. - Jay > Date: Mon, 1 Jul 2013 17:40:41 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? > > > After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > total 792 > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp > > where parse.c is changed. > > When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l > total 1944 > -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c > ../../gcc-4.7/gcc/m3cg/parse.c > > But parse.o has not changed (I can verify this by running gdb on cm3cg), and: > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > total 792 > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp > > My edits to parse.c have been undone! If I recreate the edited parse.c, > then chmod 444 parse.c and recompile, it has no effect. parse.c still > gets changed back to the unedited version. > > Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory > (I have no idea how long this has been the case), and I have not been able > to get cvs to admit to having any awareness of this directory or anything in it, > using cvs log, cvs update or cvs checkout. I even tried manually creating a > CVS subdirectory, but without getting cvs to tell me something about its current > version number of parse.c, I can't create a line in CVS/Entries for it, and cvs > continues to claim total ignorance of this file. > > What is going on here? Is parse.c (and all of m3cg) being automatically created? > From where? > > cvs update -P does not remove m3cg, BTW. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Jul 2 16:31:26 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 02 Jul 2013 09:31:26 -0500 Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? In-Reply-To: References: <51D20569.1010600@lcwb.coop> Message-ID: <51D2E43E.8020803@lcwb.coop> OK. Is it the one in m3-sys/m3cc/gcc/gcc/m3cg? This has a CVS directory, while gcc-4.5 and gcc-4.7 do not, and m3-sys/m3cc-old doesn't sound promising. Does it work the same way for all the files in m3cg? On 07/01/2013 08:48 PM, Jay K wrote: > There is one parse.c for several gcc forks. It is copied or linked by m3makefile. > > - Jay > > > Date: Mon, 1 Jul 2013 17:40:41 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? > > > > > > After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > > total 792 > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > > -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp > > > > where parse.c is changed. > > > > When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l > > total 1944 > > -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c > > ../../gcc-4.7/gcc/m3cg/parse.c > > > > But parse.o has not changed (I can verify this by running gdb on cm3cg), and: > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > > total 792 > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp > > > > My edits to parse.c have been undone! If I recreate the edited parse.c, > > then chmod 444 parse.c and recompile, it has no effect. parse.c still > > gets changed back to the unedited version. > > > > Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory > > (I have no idea how long this has been the case), and I have not been able > > to get cvs to admit to having any awareness of this directory or anything in it, > > using cvs log, cvs update or cvs checkout. I even tried manually creating a > > CVS subdirectory, but without getting cvs to tell me something about its current > > version number of parse.c, I can't create a line in CVS/Entries for it, and cvs > > continues to claim total ignorance of this file. > > > > What is going on here? Is parse.c (and all of m3cg) being automatically created? > > From where? > > > > cvs update -P does not remove m3cg, BTW. > > > > From jay.krell at cornell.edu Wed Jul 3 03:56:05 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Jul 2013 01:56:05 +0000 Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? In-Reply-To: <51D2E43E.8020803@lcwb.coop> References: <51D20569.1010600@lcwb.coop> , <51D2E43E.8020803@lcwb.coop> Message-ID: Yes, there is just one copy of the directory. Look in m3cc/src/m3makefile. Sometimes maybe a prefix is copied followed by the rest of the file, e.g. #define GCC47 ... contents of parse.c ... The #defines have a mix of meanings. GCC12 might mean exactly GCC 1.2, or it might mean 1.2 or newer. And there is GCC_APPLE, which goes along with gcc 4.2. I'm sorry about that. It could/should be cleaned up. If you really want, consider some things: 1) make entire copies of the file 2) split the file up and copy some of them, while keeping others identical Most of the code is indeed identical. So I don't like #1. In the case of #2, the bulk of the content would remain where it is, in the one parse.c, so history would be reasonable. Preserving history is of some concern, but CVS works poorly enough, and perhaps we renamed the directories in the past, so I'd be ok with having to jump around to trace history accurately. Or leave things mostly asis. And/or cleanup the meanings or "granularity" of the #defines. And/or drop support for all but the latest? I didn't get around to moving every target forward. Mainline gcc does not support OpenBSD for example, so I/we always have to do at least a tiny bit of work there. The OpenBSD ports/packages system does maintain patches for gcc. Many are outside the backend, and they are all trivial, stuff like picking size_t and pre-#definining __OpenBSD__ or such. Interix also requires moving small non-Modula-3 patches forward. iPhone/ARM_DARWIN would remain at 4.2 also, probably. I got as far there as starting up the compiler, which is pretty far. I have a number of times edited the wrong file only to have it overwritten by m3makefile. That is an unfortunate fallout of this scheme. But, as I said, most of the contents of the file are portable across several gcc versions. Hopefully I'll back to the C backend and moot this.. :( Anyway, if you look at the source and CVS, it should be /reasonably/ clear. I don't know/remember what m3cc-old is. There is some pain around "GTY". The syntax for it changed across gcc versions, like GTY struct foo vs. struct GTY foo or struct foo GTY. This is the annotation you put on types for the gcc garbage collector. So for that I did split a little bit of content into a different file. - Jay > Date: Tue, 2 Jul 2013 09:31:26 -0500 > From: rodney_bates at lcwb.coop > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? > > OK. Is it the one in m3-sys/m3cc/gcc/gcc/m3cg? This has a CVS directory, while > gcc-4.5 and gcc-4.7 do not, and m3-sys/m3cc-old doesn't sound promising. > > Does it work the same way for all the files in m3cg? > > On 07/01/2013 08:48 PM, Jay K wrote: > > There is one parse.c for several gcc forks. It is copied or linked by m3makefile. > > > > - Jay > > > > > Date: Mon, 1 Jul 2013 17:40:41 -0500 > > > From: rodney_bates at lcwb.coop > > > To: m3devel at elegosoft.com > > > Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? > > > > > > > > > After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see > > > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > > > total 792 > > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > > > -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c > > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp > > > > > > where parse.c is changed. > > > > > > When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and > > > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l > > > total 1944 > > > -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c > > > ../../gcc-4.7/gcc/m3cg/parse.c > > > > > > But parse.o has not changed (I can verify this by running gdb on cm3cg), and: > > > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > > > total 792 > > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c > > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp > > > > > > My edits to parse.c have been undone! If I recreate the edited parse.c, > > > then chmod 444 parse.c and recompile, it has no effect. parse.c still > > > gets changed back to the unedited version. > > > > > > Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory > > > (I have no idea how long this has been the case), and I have not been able > > > to get cvs to admit to having any awareness of this directory or anything in it, > > > using cvs log, cvs update or cvs checkout. I even tried manually creating a > > > CVS subdirectory, but without getting cvs to tell me something about its current > > > version number of parse.c, I can't create a line in CVS/Entries for it, and cvs > > > continues to claim total ignorance of this file. > > > > > > What is going on here? Is parse.c (and all of m3cg) being automatically created? > > > From where? > > > > > > cvs update -P does not remove m3cg, BTW. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Jul 7 04:11:18 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 6 Jul 2013 22:11:18 -0400 Subject: [M3devel] Multiple executables from the same source Message-ID: <20130707021118.GA9726@topoi.pooq.com> I'm writiing and debugging a bunch of interfaces and modules. They are all supposed to fit together into one happy executable. But of course, until I've finished debugging them they fit together into one unhappy executable. To test them properly I'd like to write a series of unit tests. To run these tests I will need to make further executables, each consisting of a test modules and several of the modules under test. Now with the usual structure of a Modula 3 workspace, there is one m3makefile and a src directory, and it makes one executable, not many, and it doesn't really give me a choice of which executable I want. In the old days of C code and Makefiles, I could have multiple targets each one being built with its own cc command with its own list of source files names. Is there anything comparable for Modula 3? The best I've come up sith so far is to have a number of directories, one for each test case, with its own m3makefile and its own symbolic link to a common src directory. Is there something better? I'm not really interested in having all the test code be part of the final application. For one thing, I'd like to be able to test multiple implementations of a single interface, such as a reference implementation and an efficient one, so that I can compare the output and complain about the differences. -- hendrik From jay.krell at cornell.edu Sun Jul 7 07:46:03 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Jul 2013 05:46:03 +0000 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <20130707021118.GA9726@topoi.pooq.com> References: <20130707021118.GA9726@topoi.pooq.com> Message-ID: I think you have multiple obvious choices, that you are aware of, that you don't think you want: 1) put it all in one src, one executable, a command line switch to choice the test case, AND have an option in the m3makefile and Main.m3 to omit the test code 1b) or just live it with it all being present all the time 2) break out the code into multiple libraries and multiple executables; including having more stuff in your public interface than you otherwise would.. "Hey, look", I've worked with a few build systems. Mostly NT Build. There seems to be some Digital (DEC) line of descent visible in about half of the programming world, and Modula-3 and NT and NT Build live there. (The other half is Unix). m3quake and NT Build have an amazing coincidence in overall design and feel. They both are declarative with an escape. NT Build is actually a thin wrapper over nmake, such that many people don't realize nmake is there, but the escape is nmake/makefile.inc. m3quake/cm3 is its own language, the declarations are actually function calls, and the escape is the fairly general scripting language. Most people just use the declarative stuff and don't break out into the programming language. (NT Build is publically available in the Windows DDK, at least until recent versions.) They both limit, mostly, source files to be in leaf directories. You can't reach around and build random source from random other places. Unless you turn it into a library or .obj. NT Build does have an obscure little used feature named UMTEST/UMAPPL. Where you can build multiple test apps in one leaf. They are afforded one source file each, and I think link to the rest of the directory, i.e. a library. In specifying these test cases though, the full generality of what you can do in a directory is lost. In m3quake/cm3-speak -- consider "import". Which executable are you importing for? One special one? All of them? The same problems.. Given the successful scale of both of these systems (really, of NT build), I suggest the designers knew very well what they were doing and anything we complain is missing, they were probably actually doing us a favor by omitting, we should live with the limitations and be happy to have received such a decent scalable design. :) > with its own m3makefile and its own symbolic link to a common src directory. And how are you going to check that into CVS and sync and build it on file systems without symlinks? Not portable. - Jay > Date: Sat, 6 Jul 2013 22:11:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: [M3devel] Multiple executables from the same source > > I'm writiing and debugging a bunch of interfaces and modules. > They are all supposed to fit together into one happy executable. > > But of course, until I've finished debugging them > they fit together into one unhappy executable. > To test them properly I'd like to write a series of unit tests. > To run these tests I will need to make further executables, > each consisting of a test modules and several of the modules under test. > > Now with the usual structure of a Modula 3 workspace, > there is one m3makefile and a src directory, and it makes one executable, > not many, > and it doesn't really give me a choice of which executable I want. > > In the old days of C code and Makefiles, I could have multiple targets > each one being built with its own cc command > with its own list of source files names. > > Is there anything comparable for Modula 3? > > The best I've come up sith so far is to have a number of directories, > one for each test case, > with its own m3makefile and its own symbolic link to a common src directory. > > Is there something better? > > I'm not really interested in having all the test code > be part of the final application. > > For one thing, > I'd like to be able to test multiple implementations of a single interface, > such as a reference implementation and an efficient one, > so that I can compare the output and complain about the differences. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 7 10:13:42 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Jul 2013 08:13:42 +0000 Subject: [M3devel] Multiple executables from the same source In-Reply-To: References: <20130707021118.GA9726@topoi.pooq.com>, Message-ID: > I'd like to be able to test multiple implementations of a single interface, I suggest you use objects here. And a common base type. Like how "interface" is interpreted in Java, C#, and COM. Modula-3 supports this well enough, just with different terminology. - Jay From: jay.krell at cornell.edu To: hendrik at topoi.pooq.com; m3devel at elegosoft.com Date: Sun, 7 Jul 2013 05:46:03 +0000 Subject: Re: [M3devel] Multiple executables from the same source I think you have multiple obvious choices, that you are aware of, that you don't think you want: 1) put it all in one src, one executable, a command line switch to choice the test case, AND have an option in the m3makefile and Main.m3 to omit the test code 1b) or just live it with it all being present all the time 2) break out the code into multiple libraries and multiple executables; including having more stuff in your public interface than you otherwise would.. "Hey, look", I've worked with a few build systems. Mostly NT Build. There seems to be some Digital (DEC) line of descent visible in about half of the programming world, and Modula-3 and NT and NT Build live there. (The other half is Unix). m3quake and NT Build have an amazing coincidence in overall design and feel. They both are declarative with an escape. NT Build is actually a thin wrapper over nmake, such that many people don't realize nmake is there, but the escape is nmake/makefile.inc. m3quake/cm3 is its own language, the declarations are actually function calls, and the escape is the fairly general scripting language. Most people just use the declarative stuff and don't break out into the programming language. (NT Build is publically available in the Windows DDK, at least until recent versions.) They both limit, mostly, source files to be in leaf directories. You can't reach around and build random source from random other places. Unless you turn it into a library or .obj. NT Build does have an obscure little used feature named UMTEST/UMAPPL. Where you can build multiple test apps in one leaf. They are afforded one source file each, and I think link to the rest of the directory, i.e. a library. In specifying these test cases though, the full generality of what you can do in a directory is lost. In m3quake/cm3-speak -- consider "import". Which executable are you importing for? One special one? All of them? The same problems.. Given the successful scale of both of these systems (really, of NT build), I suggest the designers knew very well what they were doing and anything we complain is missing, they were probably actually doing us a favor by omitting, we should live with the limitations and be happy to have received such a decent scalable design. :) > with its own m3makefile and its own symbolic link to a common src directory. And how are you going to check that into CVS and sync and build it on file systems without symlinks? Not portable. - Jay > Date: Sat, 6 Jul 2013 22:11:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: [M3devel] Multiple executables from the same source > > I'm writiing and debugging a bunch of interfaces and modules. > They are all supposed to fit together into one happy executable. > > But of course, until I've finished debugging them > they fit together into one unhappy executable. > To test them properly I'd like to write a series of unit tests. > To run these tests I will need to make further executables, > each consisting of a test modules and several of the modules under test. > > Now with the usual structure of a Modula 3 workspace, > there is one m3makefile and a src directory, and it makes one executable, > not many, > and it doesn't really give me a choice of which executable I want. > > In the old days of C code and Makefiles, I could have multiple targets > each one being built with its own cc command > with its own list of source files names. > > Is there anything comparable for Modula 3? > > The best I've come up sith so far is to have a number of directories, > one for each test case, > with its own m3makefile and its own symbolic link to a common src directory. > > Is there something better? > > I'm not really interested in having all the test code > be part of the final application. > > For one thing, > I'd like to be able to test multiple implementations of a single interface, > such as a reference implementation and an efficient one, > so that I can compare the output and complain about the differences. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Jul 7 15:08:12 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 7 Jul 2013 09:08:12 -0400 Subject: [M3devel] Multiple executables from the same source In-Reply-To: References: <20130707021118.GA9726@topoi.pooq.com> Message-ID: <20130707130811.GA9183@topoi.pooq.com> On Sun, Jul 07, 2013 at 05:46:03AM +0000, Jay K wrote: > > And how are you going to check that into CVS and sync and build it on file systems without symlinks? Instead of CVS I use monotone, which does handle symbolic links. Or I could have a makefile that makes the symbolic links as needed. > Not portable. Yes, that bothers me. It's one of the reasons the symbolic link seemed like a kludge to me. I'll look into your suggestions. -- hendrik From hendrik at topoi.pooq.com Sun Jul 7 17:58:18 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 7 Jul 2013 11:58:18 -0400 Subject: [M3devel] Multiple executables from the same source In-Reply-To: References: <20130707021118.GA9726@topoi.pooq.com> Message-ID: <20130707155818.GB10466@topoi.pooq.com> On Sun, Jul 07, 2013 at 05:46:03AM +0000, Jay K wrote: > m3quake/cm3 is its own language, the declarations are actually > function calls, and the escape is the fairly general scripting > language. Most people just use the declarative stuff and don't break > out into the programming language. So you mean I should use something like if (test) implementation("Test") program("Test") else implementation("Main") program("Main") end in the m3makefile and run it with something like cm3 -Dtest Seems to work. Thanks. Now that I know what to look for, finding http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html made it relatively straightforward. -- hendrik From hendrik at topoi.pooq.com Sun Jul 7 18:39:17 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 7 Jul 2013 12:39:17 -0400 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <20130707155818.GB10466@topoi.pooq.com> References: <20130707021118.GA9726@topoi.pooq.com> <20130707155818.GB10466@topoi.pooq.com> Message-ID: <20130707163917.GA10814@topoi.pooq.com> On Sun, Jul 07, 2013 at 11:58:18AM -0400, Hendrik Boom wrote: > On Sun, Jul 07, 2013 at 05:46:03AM +0000, Jay K wrote: > > m3quake/cm3 is its own language, the declarations are actually > > function calls, and the escape is the fairly general scripting > > language. Most people just use the declarative stuff and don't break > > out into the programming language. > > So you mean I should use something like > > > if (test) correction: if defined("test") > implementation("Test") > program("Test") > else > implementation("Main") > program("Main") > end > > in the m3makefile > > and run it with something like > > cm3 -Dtest > > Seems to work. Thanks. Now that I know what to look for, finding > http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html made it > relatively straightforward. > > -- hendrik From hendrik at topoi.pooq.com Mon Jul 8 15:45:10 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 8 Jul 2013 09:45:10 -0400 Subject: [M3devel] I don't know what changed, or when, but thanks! Message-ID: <20130708134510.GA20805@topoi.pooq.com> Years ago, when a Modula 3 program failed because I called an absent method, it was difficult findig where the error was. But yesterday, I just ran the program in m3gdb and got a backtrace after failure. Of course the backtrace was full of apparent gibberish, but right in the middle is said: at ../src/runtime/common/RTException.m3:25 #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol table. ) at ../src/runtime/ex_frame/RTExFrame.m3:29 #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. ) at ../src/runtime/common/RTType.m3:850 #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in symbol table. ) at ../src/runtime/common/RTType.m3:834 #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol table. ) at ../src/Parse.m3:115 ---Type to continue, or q to quit--- #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol table. ) at ../src/Parse.m3:354 #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol table. ) at ../src/Main.m3:202 So it was quite clear I had to look at ../src/Parse.m3:115, and it was obvious where I had left our a shift := shift line in an OVERRIDES list. -- hendrik From rodney_bates at lcwb.coop Mon Jul 8 17:36:29 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 08 Jul 2013 10:36:29 -0500 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <20130708134510.GA20805@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> Message-ID: <51DADC7D.5060606@lcwb.coop> If you get m3gdb to realize this is modula-3 code, there will be a lot more useful info in the backtrace, like parameter values. Probably just doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. If you are using the head compiler and debugger, you will need very recent ones (perhaps in the last month?), as changes in the code generator created some regressions. All that I have seen are now fixed in the current head. On 07/08/2013 08:45 AM, Hendrik Boom wrote: > Years ago, when a Modula 3 program failed because I called an absent > method, it was difficult findig where the error was. > > But yesterday, I just ran the program in m3gdb and got a backtrace > after failure. > > Of course the backtrace was full of apparent gibberish, but right in > the middle is said: > > at ../src/runtime/common/RTException.m3:25 > #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol > table. > ) at ../src/runtime/ex_frame/RTExFrame.m3:29 > #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. > ) at ../src/runtime/common/RTType.m3:850 > #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in > symbol table. > ) > at ../src/runtime/common/RTType.m3:834 > #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol > table. > ) at ../src/Parse.m3:115 > ---Type to continue, or q to quit--- > #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol > table. > ) at ../src/Parse.m3:354 > #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol > table. > ) at ../src/Main.m3:202 > > > So it was quite clear I had to look at ../src/Parse.m3:115, and it was > obvious where I had left our a shift := shift line in an OVERRIDES > list. > > -- hendrik > > From rodney_bates at lcwb.coop Mon Jul 8 17:51:41 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 08 Jul 2013 10:51:41 -0500 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <20130707021118.GA9726@topoi.pooq.com> References: <20130707021118.GA9726@topoi.pooq.com> Message-ID: <51DAE00D.3090508@lcwb.coop> On 07/06/2013 09:11 PM, Hendrik Boom wrote: > I'm writiing and debugging a bunch of interfaces and modules. > They are all supposed to fit together into one happy executable. > > But of course, until I've finished debugging them > they fit together into one unhappy executable. > To test them properly I'd like to write a series of unit tests. > To run these tests I will need to make further executables, > each consisting of a test modules and several of the modules under test. > > Now with the usual structure of a Modula 3 workspace, > there is one m3makefile and a src directory, and it makes one executable, > not many, > and it doesn't really give me a choice of which executable I want. > > In the old days of C code and Makefiles, I could have multiple targets > each one being built with its own cc command > with its own list of source files names. > > Is there anything comparable for Modula 3? > > The best I've come up sith so far is to have a number of directories, > one for each test case, > with its own m3makefile and its own symbolic link to a common src directory. I have one project with three executables and a majority of the code shared. I am using essentially this scheme, but instead of the symlinks in the directories, I have 'include_dir("../common/src")' in the m3makefiles of the main programs. common/src has its m3makefile for all the stuff in common. This means means every main program has to independently compile all the common stuff and keep its own copies thereof. But disk is cheap and plentiful, and 200K..300K SLOC compiles from scratch fast enough. Someday, when bored, I plan to make the common stuff a separate library package. But then I will have to remember to recompile it when it changes, before compiling a main package. I have often thought about a second level of automatic, inter-package recompilation. It would have saved me some grief on occasions. But it could introduce new problems too. > > Is there something better? > > I'm not really interested in having all the test code > be part of the final application. > > For one thing, > I'd like to be able to test multiple implementations of a single interface, > such as a reference implementation and an efficient one, > so that I can compare the output and complain about the differences. > > -- hendrik > From hendrik at topoi.pooq.com Mon Jul 8 18:25:40 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 8 Jul 2013 12:25:40 -0400 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <51DAE00D.3090508@lcwb.coop> References: <20130707021118.GA9726@topoi.pooq.com> <51DAE00D.3090508@lcwb.coop> Message-ID: <20130708162540.GA22041@topoi.pooq.com> On Mon, Jul 08, 2013 at 10:51:41AM -0500, Rodney M. Bates wrote: > > > On 07/06/2013 09:11 PM, Hendrik Boom wrote: > >I'm writiing and debugging a bunch of interfaces and modules. > >They are all supposed to fit together into one happy executable. > > > >But of course, until I've finished debugging them > > they fit together into one unhappy executable. > >To test them properly I'd like to write a series of unit tests. > >To run these tests I will need to make further executables, > > each consisting of a test modules and several of the modules under test. > > > >Now with the usual structure of a Modula 3 workspace, > > there is one m3makefile and a src directory, and it makes one executable, > > not many, > > and it doesn't really give me a choice of which executable I want. > > > >In the old days of C code and Makefiles, I could have multiple targets > > each one being built with its own cc command > > with its own list of source files names. > > > >Is there anything comparable for Modula 3? > > > >The best I've come up sith so far is to have a number of directories, > > one for each test case, > > with its own m3makefile and its own symbolic link to a common src directory. > > I have one project with three executables and a majority of the code shared. I > am using essentially this scheme, but instead of the symlinks in the directories, > I have 'include_dir("../common/src")' in the m3makefiles of the main programs. > common/src has its m3makefile for all the stuff in common. Is this a way of getting cm3 to search ../common/src as sell as the src it usually looks through? That may be what I wanted ... but IF statements in m3makefiles suffice for now. It's useful to know that include_dir is available, though. Is there any advice how to make sure the variable names I use in an m3makefiles don't confllict with the ones that cm3 might be using to manage the compilation? > > This means means every main program has to independently compile all the common > stuff and keep its own copies thereof. But disk is cheap and plentiful, > and 200K..300K SLOC compiles from scratch fast enough. Independently compiling all that stuff is what I originally wanted -- it would give me the option of trying independent and very different implementations for some interfaces so as to discover hidden logical dependencies. And the extra disk space is not that much space -- considering that it only needs to be tied up during testing, -- hendrik From hendrik at topoi.pooq.com Mon Jul 8 18:30:38 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 8 Jul 2013 12:30:38 -0400 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <51DADC7D.5060606@lcwb.coop> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> Message-ID: <20130708163038.GB22041@topoi.pooq.com> On Mon, Jul 08, 2013 at 10:36:29AM -0500, Rodney M. Bates wrote: > If you get m3gdb to realize this is modula-3 code, there will be a lot > more useful info in the backtrace, like parameter values. Probably just > doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. Yes, that would probably help. > > If you are using the head compiler and debugger, you will need very > recent ones (perhaps in the last month?), as changes in the code > generator created some regressions. All that I have seen are now > fixed in the current head. Time to upgrade, then. Please understand, I was being genuinely happy, not complaining in a sarcastic way. Knowing just where I called into deep space was a huge time-saver. -- hendrik > > On 07/08/2013 08:45 AM, Hendrik Boom wrote: > >Years ago, when a Modula 3 program failed because I called an absent > >method, it was difficult findig where the error was. > > > >But yesterday, I just ran the program in m3gdb and got a backtrace > >after failure. > > > >Of course the backtrace was full of apparent gibberish, but right in > >the middle is said: > > > > at ../src/runtime/common/RTException.m3:25 > >#14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol > >table. > >) at ../src/runtime/ex_frame/RTExFrame.m3:29 > >#15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. > >) at ../src/runtime/common/RTType.m3:850 > >#16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in > >symbol table. > >) > > at ../src/runtime/common/RTType.m3:834 > >#17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol > >table. > >) at ../src/Parse.m3:115 > >---Type to continue, or q to quit--- > >#18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol > >table. > >) at ../src/Parse.m3:354 > >#19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol > >table. > >) at ../src/Main.m3:202 > > > > > >So it was quite clear I had to look at ../src/Parse.m3:115, and it was > >obvious where I had left our a shift := shift line in an OVERRIDES > >list. > > > >-- hendrik > > > > > From rodney_bates at lcwb.coop Mon Jul 8 20:20:05 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 08 Jul 2013 13:20:05 -0500 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <20130708163038.GB22041@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> Message-ID: <51DB02D5.8070209@lcwb.coop> On 07/08/2013 11:30 AM, Hendrik Boom wrote: > On Mon, Jul 08, 2013 at 10:36:29AM -0500, Rodney M. Bates wrote: >> If you get m3gdb to realize this is modula-3 code, there will be a lot >> more useful info in the backtrace, like parameter values. Probably just >> doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. > > Yes, that would probably help. >> >> If you are using the head compiler and debugger, you will need very >> recent ones (perhaps in the last month?), as changes in the code >> generator created some regressions. All that I have seen are now >> fixed in the current head. > > Time to upgrade, then. > > Please understand, I was being genuinely happy, not complaining in a > sarcastic way. Yes, I read it that way, but I can sometimes get confused about that. BTW, you can also catch exception that is later handled, at the point where it is raised, by setting (in advance) a breakpoint in a place like Raise in the RTS. You could get lots of false hits this way though, if raise-handle of other exceptions is something that is happening routinely. > > Knowing just where I called into deep space was a huge time-saver. > > -- hendrik > >> >> On 07/08/2013 08:45 AM, Hendrik Boom wrote: >>> Years ago, when a Modula 3 program failed because I called an absent >>> method, it was difficult findig where the error was. >>> >>> But yesterday, I just ran the program in m3gdb and got a backtrace >>> after failure. >>> >>> Of course the backtrace was full of apparent gibberish, but right in >>> the middle is said: >>> >>> at ../src/runtime/common/RTException.m3:25 >>> #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol >>> table. >>> ) at ../src/runtime/ex_frame/RTExFrame.m3:29 >>> #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. >>> ) at ../src/runtime/common/RTType.m3:850 >>> #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in >>> symbol table. >>> ) >>> at ../src/runtime/common/RTType.m3:834 >>> #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol >>> table. >>> ) at ../src/Parse.m3:115 >>> ---Type to continue, or q to quit--- >>> #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol >>> table. >>> ) at ../src/Parse.m3:354 >>> #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol >>> table. >>> ) at ../src/Main.m3:202 >>> >>> >>> So it was quite clear I had to look at ../src/Parse.m3:115, and it was >>> obvious where I had left our a shift := shift line in an OVERRIDES >>> list. >>> >>> -- hendrik >>> >>> >> > From rodney_bates at lcwb.coop Mon Jul 8 20:13:16 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 08 Jul 2013 13:13:16 -0500 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <20130708162540.GA22041@topoi.pooq.com> References: <20130707021118.GA9726@topoi.pooq.com> <51DAE00D.3090508@lcwb.coop> <20130708162540.GA22041@topoi.pooq.com> Message-ID: <51DB013C.6030200@lcwb.coop> On 07/08/2013 11:25 AM, Hendrik Boom wrote: > On Mon, Jul 08, 2013 at 10:51:41AM -0500, Rodney M. Bates wrote: >> >> >> On 07/06/2013 09:11 PM, Hendrik Boom wrote: >>> I'm writiing and debugging a bunch of interfaces and modules. >>> They are all supposed to fit together into one happy executable. >>> >>> But of course, until I've finished debugging them >>> they fit together into one unhappy executable. >>> To test them properly I'd like to write a series of unit tests. >>> To run these tests I will need to make further executables, >>> each consisting of a test modules and several of the modules under test. >>> >>> Now with the usual structure of a Modula 3 workspace, >>> there is one m3makefile and a src directory, and it makes one executable, >>> not many, >>> and it doesn't really give me a choice of which executable I want. >>> >>> In the old days of C code and Makefiles, I could have multiple targets >>> each one being built with its own cc command >>> with its own list of source files names. >>> >>> Is there anything comparable for Modula 3? >>> >>> The best I've come up sith so far is to have a number of directories, >>> one for each test case, >>> with its own m3makefile and its own symbolic link to a common src directory. >> >> I have one project with three executables and a majority of the code shared. I >> am using essentially this scheme, but instead of the symlinks in the directories, >> I have 'include_dir("../common/src")' in the m3makefiles of the main programs. >> common/src has its m3makefile for all the stuff in common. > > Is this a way of getting cm3 to search ../common/src as sell as the src > it usually looks through? Yes,, it uses ../common/src/m3makefile and whatever it refers to. I don't know the precise semantics, but I imagine it just interprets the contents of the included m3makefile in place of the include_dir. > > That may be what I wanted ... but IF statements in m3makefiles suffice > for now. > > It's useful to know that include_dir is available, though. > > Is there any advice how to make sure the variable names I use in an > m3makefiles don't confllict with the ones that cm3 might be using to > manage the compilation? > I don't think there is anything graceful here, other than try it and see if things blow up. >> >> This means means every main program has to independently compile all the common >> stuff and keep its own copies thereof. But disk is cheap and plentiful, >> and 200K..300K SLOC compiles from scratch fast enough. > > Independently compiling all that stuff is what I originally wanted -- > it would give me the option of trying independent and very different > implementations for some interfaces so as to discover hidden logical > dependencies. > > And the extra disk space is not that much space -- considering that > it only needs to be tied up during testing, > > -- hendrik > From hendrik at topoi.pooq.com Mon Jul 8 22:25:39 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 8 Jul 2013 16:25:39 -0400 Subject: [M3devel] typo in http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html Message-ID: <20130708202539.GA30241@topoi.pooq.com> The paragraph in section 9.8 that defines 'defined' has a typo: evaluated before begin passed to defined. instead of evaluated before being passed to defined. -- hendrik From mika at async.caltech.edu Thu Jul 11 11:08:04 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Thu, 11 Jul 2013 02:08:04 -0700 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <51DADC7D.5060606@lcwb.coop> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> Message-ID: <20130711090804.939171A207D@async.async.caltech.edu> This is just a pet peeve of mine, but I never remember to capitalize "Modula-3" right. There is no way to make m3gdb also recognize set lang m3 set lang modula3 set lang modula-3 set lang m0dulaIII etc...? "Rodney M. Bates" writes: >If you get m3gdb to realize this is modula-3 code, there will be a lot >more useful info in the backtrace, like parameter values. Probably just >doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. > >If you are using the head compiler and debugger, you will need very >recent ones (perhaps in the last month?), as changes in the code >generator created some regressions. All that I have seen are now >fixed in the current head. > >On 07/08/2013 08:45 AM, Hendrik Boom wrote: >> Years ago, when a Modula 3 program failed because I called an absent >> method, it was difficult findig where the error was. >> >> But yesterday, I just ran the program in m3gdb and got a backtrace >> after failure. >> >> Of course the backtrace was full of apparent gibberish, but right in >> the middle is said: >> >> at ../src/runtime/common/RTException.m3:25 >> #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol >> table. >> ) at ../src/runtime/ex_frame/RTExFrame.m3:29 >> #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. >> ) at ../src/runtime/common/RTType.m3:850 >> #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in >> symbol table. >> ) >> at ../src/runtime/common/RTType.m3:834 >> #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol >> table. >> ) at ../src/Parse.m3:115 >> ---Type to continue, or q to quit--- >> #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol >> table. >> ) at ../src/Parse.m3:354 >> #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol >> table. >> ) at ../src/Main.m3:202 >> >> >> So it was quite clear I had to look at ../src/Parse.m3:115, and it was >> obvious where I had left our a shift := shift line in an OVERRIDES >> list. >> >> -- hendrik >> >> From wagner at elego.de Thu Jul 11 11:20:18 2013 From: wagner at elego.de (Olaf Wagner) Date: Thu, 11 Jul 2013 11:20:18 +0200 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <20130711090804.939171A207D@async.async.caltech.edu> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130711090804.939171A207D@async.async.caltech.edu> Message-ID: <20130711112018.3bf3ba6f.wagner@elego.de> On Thu, 11 Jul 2013 02:08:04 -0700 mika at async.caltech.edu wrote: > This is just a pet peeve of mine, but I never remember to capitalize "Modula-3" right. > There is no way to make m3gdb also recognize > > set lang m3 +1 > set lang modula3 > set lang modula-3 > set lang m0dulaIII -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 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 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Thu Jul 11 17:56:35 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Thu, 11 Jul 2013 08:56:35 -0700 Subject: [M3devel] netobj bug report In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF2F168037@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF2F168037@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <20130711155635.869211A207D@async.async.caltech.edu> The code in CM3 is the same. I am 95% certain this is a bug. The logic just doesn't make sense. All you should have to do to reproduce it is the following: instantiate a subtype of NetObj.T without exporting it. Then try to Pickle it. Your program I think will crash (for no good reason). Your program I think will not crash if you do export it. The logic is checking for a surrogate and crashing if you attempt to pickle one: > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; The problem is that x.r is only non-NIL once you export the object. For a new object that has not been exported, x.r is NIL. Therefore it is of type Transport.Location and appears to be a surrogate, even though it is not a surrogate. The test should be IF x.r = NIL OR NOT ISTYPE... Mika "Coleburn, Randy" writes: >Hi Mika: > >I'm deep in the middle of some other stuff, but read your post with interes= >t because I've done a LOT of work with both Pickles and Network Objects. > >On the surface, I'm not sure whether this is a bug or not. I've never enco= >untered this problem before. But, my brain is in left-field right now with= > all else I have going on. > >I know that I always used the Pickle2 (2nd generation of pickles) to get ar= >ound some problems with the first generation. I never used PM3, just CM3 a= >nd the original "SRC-Systems Research Center" versions. > >I know you can also write and register special "pickler" procedures for any= > particular object to get around problems with the default pickling procedu= >res (read/write). I've had to do this on occasion both to resolve problems= > and to increase performance. I can provide examples if you need them. > >--Randy > >Randy C. Coleburn, CISSP-ISSEP, GCED >Corporate Information Security Officer (CISO) >Scientific Research Corporation > >-----Original Message----- >From: mika at async.caltech.edu [mailto:mika at async.caltech.edu]=20 >Sent: Thursday, June 27, 2013 7:01 PM >To: m3devel at elegosoft.com >Subject: EXT:[M3devel] netobj bug report > >Hi m3devel, > >I think I found a bug in the Network Objects code. > >Here is what I was doing: I made an object that I wanted to export using Ne= >twork Objects, but I *also* wanted to Pickle the object locally (for persis= >tence). > >I find that if I create the object and try to pickle it, I get a Pickle err= >or "Can't pickle a surrogate object". =20 > >The source of the error is in StubLib.m3, the Pickle special that is record= >ed for network objects: > >PROCEDURE OutSpecial(self: Pickle.Special; > r: REFANY; > writer: Pickle.Writer) > RAISES {Pickle.Error, Wr.Failure, Thread.Alerted} =3D > BEGIN > TYPECASE writer OF > | SpecWr(wtr) =3D> OutRef(wtr.c, r); > ELSE > TYPECASE r OF > | NetObj.T(x) =3D> > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; > ELSE RAISE Pickle.Error("Can't Pickle Rd.T or Wr.T"); > END; > END; > END OutSpecial; > >(In CM3, OutSpecial2 has the same bug for Pickle2 pickles. PM3 doesn't hav= >e Pickle2 nor OutSpecial2.) > >The problem is the test > > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; > >The intent, I think, is that an object that is remote (that is, has x.r of = >type Transport.Location) should not be pickle-able. > >The problem is that x.r is initially NIL, and NIL is a member of Transport.= >Location. > >My workaround is to FIRST export the object before attempting to Pickle it.= > This works fine but it shouldn't be necessary, should it? What if I don'= >t want to export the object, but just pickle it? > >I believe the test should be changed to be > >IF x.r =3D NIL OR NOT ISTYPE(x.r, Transport.Location) THEN... > > Mika > From rodney_bates at lcwb.coop Thu Jul 11 22:07:23 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 11 Jul 2013 15:07:23 -0500 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <20130711090804.939171A207D@async.async.caltech.edu> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130711090804.939171A207D@async.async.caltech.edu> Message-ID: <51DF107B.9020600@lcwb.coop> On 07/11/2013 04:08 AM, mika at async.caltech.edu wrote: > This is just a pet peeve of mine, but I never remember to capitalize "Modula-3" right. > There is no way to make m3gdb also recognize > > set lang m3 > set lang modula3 > set lang modula-3 > set lang m0dulaIII Hmm,, I thought I had implemented recognition of several variants. From: modula3.elegosoft.com/cm3/doc/help/m3gdb/m3gdb-onepage.html#id372899 "In case you have trouble remembering which spelling of the language name to use, it accepts the cartesian product of "Modula" spelled out or abbreviated with a single "M", lowercase/uppercase "M", and with/without the hyphen." But this is for the "info Modula-3 command, not "set lang Modula-3". I'll add that to my list. I may not do the arbitrary mixed case, nor the Roman numeral, though, just yet :-). > > etc...? > > "Rodney M. Bates" writes: >> If you get m3gdb to realize this is modula-3 code, there will be a lot >> more useful info in the backtrace, like parameter values. Probably just >> doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. >> >> If you are using the head compiler and debugger, you will need very >> recent ones (perhaps in the last month?), as changes in the code >> generator created some regressions. All that I have seen are now >> fixed in the current head. >> >> On 07/08/2013 08:45 AM, Hendrik Boom wrote: >>> Years ago, when a Modula 3 program failed because I called an absent >>> method, it was difficult findig where the error was. >>> >>> But yesterday, I just ran the program in m3gdb and got a backtrace >>> after failure. >>> >>> Of course the backtrace was full of apparent gibberish, but right in >>> the middle is said: >>> >>> at ../src/runtime/common/RTException.m3:25 >>> #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol >>> table. >>> ) at ../src/runtime/ex_frame/RTExFrame.m3:29 >>> #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. >>> ) at ../src/runtime/common/RTType.m3:850 >>> #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in >>> symbol table. >>> ) >>> at ../src/runtime/common/RTType.m3:834 >>> #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol >>> table. >>> ) at ../src/Parse.m3:115 >>> ---Type to continue, or q to quit--- >>> #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol >>> table. >>> ) at ../src/Parse.m3:354 >>> #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol >>> table. >>> ) at ../src/Main.m3:202 >>> >>> >>> So it was quite clear I had to look at ../src/Parse.m3:115, and it was >>> obvious where I had left our a shift := shift line in an OVERRIDES >>> list. >>> >>> -- hendrik >>> >>> > From hendrik at topoi.pooq.com Mon Jul 15 18:59:53 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 15 Jul 2013 12:59:53 -0400 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130708163038.GB22041@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> Message-ID: <20130715165952.GA6645@topoi.pooq.com> On Mon, Jul 08, 2013 at 12:30:38PM -0400, Hendrik Boom wrote: > On Mon, Jul 08, 2013 at 10:36:29AM -0500, Rodney M. Bates wrote: > > If you get m3gdb to realize this is modula-3 code, there will be a lot > > more useful info in the backtrace, like parameter values. Probably just > > doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. > > Yes, that would probably help. > > > > If you are using the head compiler and debugger, you will need very > > recent ones (perhaps in the last month?), as changes in the code > > generator created some regressions. All that I have seen are now > > fixed in the current head. > > Time to upgrade, then. I'm currently running version 5.8.6, which identifies itself as last updated on 2010-04-11. Is that still the latest release? I haven't found a newer. Does it come ddown to checking out current source from cvs and using my existing Modula 3 to compile it? And does cvsup work again? -- hendrik From rodney_bates at lcwb.coop Mon Jul 15 19:43:17 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 15 Jul 2013 12:43:17 -0500 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130715165952.GA6645@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> Message-ID: <51E434B5.3000706@lcwb.coop> On 07/15/2013 11:59 AM, Hendrik Boom wrote: > On Mon, Jul 08, 2013 at 12:30:38PM -0400, Hendrik Boom wrote: >> On Mon, Jul 08, 2013 at 10:36:29AM -0500, Rodney M. Bates wrote: >>> If you get m3gdb to realize this is modula-3 code, there will be a lot >>> more useful info in the backtrace, like parameter values. Probably just >>> doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. >> >> Yes, that would probably help. >>> >>> If you are using the head compiler and debugger, you will need very >>> recent ones (perhaps in the last month?), as changes in the code >>> generator created some regressions. All that I have seen are now >>> fixed in the current head. >> >> Time to upgrade, then. > > I'm currently running version 5.8.6, which identifies itself as last > updated on 2010-04-11. Is that still the latest release? I haven't > found a newer. I think that is the latest release, or maybe the slightly updated cvs release branch. > > Does it come ddown to checking out current source from cvs and using > my existing Modula 3 to compile it? > If you are using or want to use the head version, yes. If you are using the release compiler and debugger, I think most or all of the regressions I referred to have happened since the release, so using that compiler may give you pretty much all m3gdb function as exists. I don't remember adding much new function in a while. It is possible however, to get the latest m3gdb from cvs head and compile and use it along with any of various older compilers and libraries, even PM3, EZM3, or, (gasp,) SRC M3. I always try to make m3gdb remain compatible with all the older compilers, whenever I add anything. > And does cvsup work again? I don't know about this. > > -- hendrik > From hendrik at topoi.pooq.com Thu Jul 18 19:14:56 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 18 Jul 2013 13:14:56 -0400 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <51E434B5.3000706@lcwb.coop> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> <51E434B5.3000706@lcwb.coop> Message-ID: <20130718171455.GA2631@topoi.pooq.com> On Mon, Jul 15, 2013 at 12:43:17PM -0500, Rodney M. Bates wrote: > > If you are using the release compiler and debugger, I think most or > all of the regressions I referred to have happened since the release, > so using that compiler may give you pretty much all m3gdb function > as exists. I don't remember adding much new function in a while. Just to be clear, by "the regressions since the release" do you mean problems that have appeaared since the release, or problems that have been fixed since the releases. > > It is possible however, to get the latest m3gdb from cvs head and compile > and use it along with any of various older compilers and libraries, > even PM3, EZM3, or, (gasp,) SRC M3. I always try to make m3gdb remain > compatible with all the older compilers, whenever I add anything. I have to say, still maintaining compatibility with SRC M3 is amazing. -- hendrik From dragisha at m3w.org Sun Jul 21 15:33:12 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Jul 2013 15:33:12 +0200 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130718171455.GA2631@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> <51E434B5.3000706@lcwb.coop> <20130718171455.GA2631@topoi.pooq.com> Message-ID: It's problems that have appeared, by definition of regression. -- Dragi?a Duri? dragisha at m3w.org On Jul 18, 2013, at 7:14 PM, Hendrik Boom wrote: > Just to be clear, by "the regressions since the release" do you mean > problems that have appeaared since the release, or problems that have > been fixed since the > releases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Jul 21 17:46:44 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Jul 2013 10:46:44 -0500 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130718171455.GA2631@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> <51E434B5.3000706@lcwb.coop> <20130718171455.GA2631@topoi.pooq.com> Message-ID: <51EC0264.600@lcwb.coop> On 07/18/2013 12:14 PM, Hendrik Boom wrote: > On Mon, Jul 15, 2013 at 12:43:17PM -0500, Rodney M. Bates wrote: >> >> If you are using the release compiler and debugger, I think most or >> all of the regressions I referred to have happened since the release, >> so using that compiler may give you pretty much all m3gdb function >> as exists. I don't remember adding much new function in a while. > > Just to be clear, by "the regressions since the release" do you mean > problems that have appeaared since the release, or problems that have > been fixed since the > releases. > Yes, I meant regressions that first appeared since the release. Not that there aren't heaps of bugs in m3gdb and its gcc-backend support, in the release and the head. I have probably a couple of dozen handwritten sheets with to-do notes for m3gdb. But there is a lot that does work. >> >> It is possible however, to get the latest m3gdb from cvs head and compile >> and use it along with any of various older compilers and libraries, >> even PM3, EZM3, or, (gasp,) SRC M3. I always try to make m3gdb remain >> compatible with all the older compilers, whenever I add anything. > > I have to say, still maintaining compatibility with SRC M3 is amazing. > > -- hendrik > From rodney_bates at lcwb.coop Sun Jul 21 17:52:22 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Jul 2013 10:52:22 -0500 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130718171455.GA2631@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> <51E434B5.3000706@lcwb.coop> <20130718171455.GA2631@topoi.pooq.com> Message-ID: <51EC03B6.80103@lcwb.coop> On 07/18/2013 12:14 PM, Hendrik Boom wrote: > On Mon, Jul 15, 2013 at 12:43:17PM -0500, Rodney M. Bates wrote: >> >> If you are using the release compiler and debugger, I think most or >> all of the regressions I referred to have happened since the release, >> so using that compiler may give you pretty much all m3gdb function >> as exists. I don't remember adding much new function in a while. > > Just to be clear, by "the regressions since the release" do you mean > problems that have appeaared since the release, or problems that have > been fixed since the > releases. > >> >> It is possible however, to get the latest m3gdb from cvs head and compile >> and use it along with any of various older compilers and libraries, >> even PM3, EZM3, or, (gasp,) SRC M3. I always try to make m3gdb remain >> compatible with all the older compilers, whenever I add anything. > > I have to say, still maintaining compatibility with SRC M3 is amazing. Well, thank you. Actually, it's mostly just work and intention. Whenever some compiler change alters the runtime organization or the debug info, I don't strip out or modify what's there, I just add new alternative code and some detection of which to use. In a few places, it is difficult or impossible to distinguish something. A totally reworked debug info system, probably dwarf, would be refreshing, but it's a big job and there are priorities. > > -- hendrik > From rodney_bates at lcwb.coop Wed Jul 24 16:10:31 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Jul 2013 09:10:31 -0500 Subject: [M3devel] Pickles, TextLiterals, and word size Message-ID: <51EFE057.4030301@lcwb.coop> There is what I would call a bug in TextLiteral.i3 whose effect is that a TextLiteral.T has a different fingerprint on 32- and 64-bit machines. So you can't pickle a Text literal on one word-sized machine and unpickle it on the other. But fixing this will have the effect of invalidating any existing pickles written on a 64-bit machine before the fix, so they can't be read after the fix, even on a 64-bit machine. They would have to be rewritten after the fix. Is anybody doing the latter? Would having to recreate your pickles be a problem? Apparently, nobody is going cross-word-size, or we'd have heard about it. I would like to fix it properly, but don't want to undermine anybody's working system. From hendrik at topoi.pooq.com Wed Jul 24 17:34:47 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 24 Jul 2013 11:34:47 -0400 Subject: [M3devel] Pickles, TextLiterals, and word size In-Reply-To: <51EFE057.4030301@lcwb.coop> References: <51EFE057.4030301@lcwb.coop> Message-ID: <20130724153447.GA12587@topoi.pooq.com> On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote: > There is what I would call a bug in TextLiteral.i3 whose effect is that a > TextLiteral.T has a different fingerprint on 32- and 64-bit machines. > So you can't pickle a Text literal on one word-sized machine and unpickle > it on the other. > > But fixing this will have the effect of invalidating any existing pickles > written on a 64-bit machine before the fix, so they can't be read after > the fix, even on a 64-bit machine. They would have to be rewritten after > the fix. Ah! The problems of long-term compatibility! Is there any way of looking at a a pickle and determining whether it comes from a 32- of 64- bit machine? It there a way of special-casing the specific fingerprint that's about to be invalidated, so as to convert it properly on input only, while generating the new one on output? > > Is anybody doing the latter? Would having to recreate your pickles be a > problem? Apparently, nobody is going cross-word-size, or we'd have heard > about it. > > I would like to fix it properly, but don't want to undermine anybody's > working system. > From rcolebur at SCIRES.COM Wed Jul 24 19:03:12 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 24 Jul 2013 17:03:12 +0000 Subject: [M3devel] Pickles, TextLiterals, and word size In-Reply-To: <20130724153447.GA12587@topoi.pooq.com> References: <51EFE057.4030301@lcwb.coop>, <20130724153447.GA12587@topoi.pooq.com> Message-ID: <2CE8061F-4DF0-4645-AADB-F1582EDEDD73@SCIRES.COM> Hendrik raises some good questions. It would be great if "the fix" could be implemented in a way that either self-corrects for any pickles written prior to "the fix", or at least presents a run-time notification of a problem, but if this can't be done, I vote to go ahead with "the fix" and we will deal with it on a case-by-case basis. I've written a fair amount of stuff that uses pickles to persist object data on secondary storage, so I will have to deal with that, but I think it is more important this problem gets solved. Thanks, Randy Coleburn Sent from my iPad On Jul 24, 2013, at 11:34 AM, "Hendrik Boom" wrote: > On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote: >> There is what I would call a bug in TextLiteral.i3 whose effect is that a >> TextLiteral.T has a different fingerprint on 32- and 64-bit machines. >> So you can't pickle a Text literal on one word-sized machine and unpickle >> it on the other. >> >> But fixing this will have the effect of invalidating any existing pickles >> written on a 64-bit machine before the fix, so they can't be read after >> the fix, even on a 64-bit machine. They would have to be rewritten after >> the fix. > > Ah! The problems of long-term compatibility! > > Is there any way of looking at a a pickle and determining whether it > comes from a 32- of 64- bit machine? > > It there a way of special-casing the specific fingerprint that's about > to be invalidated, so as to convert it properly on input only, while > generating the new one on output? > >> >> Is anybody doing the latter? Would having to recreate your pickles be a >> problem? Apparently, nobody is going cross-word-size, or we'd have heard >> about it. >> >> I would like to fix it properly, but don't want to undermine anybody's >> working system. >> From rodney_bates at lcwb.coop Wed Jul 24 19:14:39 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Jul 2013 12:14:39 -0500 Subject: [M3devel] Pickles, TextLiterals, and word size In-Reply-To: <20130724153447.GA12587@topoi.pooq.com> References: <51EFE057.4030301@lcwb.coop> <20130724153447.GA12587@topoi.pooq.com> Message-ID: <51F00B7F.9020705@lcwb.coop> On 07/24/2013 10:34 AM, Hendrik Boom wrote: > On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote: >> There is what I would call a bug in TextLiteral.i3 whose effect is that a >> TextLiteral.T has a different fingerprint on 32- and 64-bit machines. >> So you can't pickle a Text literal on one word-sized machine and unpickle >> it on the other. >> >> But fixing this will have the effect of invalidating any existing pickles >> written on a 64-bit machine before the fix, so they can't be read after >> the fix, even on a 64-bit machine. They would have to be rewritten after >> the fix. > > Ah! The problems of long-term compatibility! > > Is there any way of looking at a a pickle and determining whether it > comes from a 32- of 64- bit machine? Yes, the pickle contains word size, LONGINT/LONGCARD size, floating point representation, endianness, lazy alignment, maximum alignment, record alignment, and now, widechar size, all for the system it was written on. > > It there a way of special-casing the specific fingerprint that's about > to be invalidated, so as to convert it properly on input only, while > generating the new one on output? > Yes, I thought about this. It would not be hard to find out what the two fingerprints are and test one read from a pickle against these values. But the problem is, there is an unbounded set of types that would depend indirectly on this, and they can't all be accounted for. Using, e.g., BITSIZE(INTEGER) as a bound in a range is the way this is happening it the subject case. Hmm, maybe I could just do the specific derived fingerprints for a TextLiteral.T, and that would be good enough. Let the programmer be responsible for other types. I think it would fix the immediate problem without undermining anything existing. I already have file dumps I can dig the values out of. I'll look into that. Thanks! >> >> Is anybody doing the latter? Would having to recreate your pickles be a >> problem? Apparently, nobody is going cross-word-size, or we'd have heard >> about it. >> >> I would like to fix it properly, but don't want to undermine anybody's >> working system. >> > From rodney_bates at lcwb.coop Wed Jul 24 22:59:12 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Jul 2013 15:59:12 -0500 Subject: [M3devel] Pickles, TextLiterals, and word size In-Reply-To: <51F00B7F.9020705@lcwb.coop> References: <51EFE057.4030301@lcwb.coop> <20130724153447.GA12587@topoi.pooq.com> <51F00B7F.9020705@lcwb.coop> Message-ID: <51F04020.1070200@lcwb.coop> On 07/24/2013 12:14 PM, Rodney M. Bates wrote: > > > On 07/24/2013 10:34 AM, Hendrik Boom wrote: >> On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote: >>> There is what I would call a bug in TextLiteral.i3 whose effect is that a >>> TextLiteral.T has a different fingerprint on 32- and 64-bit machines. >>> So you can't pickle a Text literal on one word-sized machine and unpickle >>> it on the other. >>> >>> But fixing this will have the effect of invalidating any existing pickles >>> written on a 64-bit machine before the fix, so they can't be read after >>> the fix, even on a 64-bit machine. They would have to be rewritten after >>> the fix. >> >> Ah! The problems of long-term compatibility! >> >> Is there any way of looking at a a pickle and determining whether it >> comes from a 32- of 64- bit machine? > > Yes, the pickle contains word size, LONGINT/LONGCARD size, floating > point representation, endianness, lazy alignment, maximum alignment, > record alignment, and now, widechar size, all for the system it was > written on. > > >> >> It there a way of special-casing the specific fingerprint that's about >> to be invalidated, so as to convert it properly on input only, while >> generating the new one on output? >> > > Yes, I thought about this. It would not be hard to find out what the > two fingerprints are and test one read from a pickle against these values. > > But the problem is, there is an unbounded set of types that would depend > indirectly on this, and they can't all be accounted for. Using, e.g., > BITSIZE(INTEGER) as a bound in a range is the way this is happening > it the subject case. > > Hmm, maybe I could just do the specific derived fingerprints for a > TextLiteral.T, and that would be good enough. Let the programmer be > responsible for other types. I think it would fix the immediate > problem without undermining anything existing. No, that won't work either. That would only fix the case where the TextLiteral is the top-level, and thus only, "object" in a pickle. Not very likely. When the TextLiteral is a field/element of some containing object, it is the topmost object in the entire pickle whose fingerprint is used to find the type in the reading program. Actually, pickling a TextLiteral might not be very common at all. > > I already have file dumps I can dig the values out of. I'll look > into that. Thanks! > > >>> >>> Is anybody doing the latter? Would having to recreate your pickles be a >>> problem? Apparently, nobody is going cross-word-size, or we'd have heard >>> about it. >>> >>> I would like to fix it properly, but don't want to undermine anybody's >>> working system. >>> >> > > From mika at async.caltech.edu Sat Jul 27 05:07:17 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 26 Jul 2013 20:07:17 -0700 Subject: [M3devel] netobj bug report In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF2F168037@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF2F168037@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <20130727030717.095FD1A208C@async.async.caltech.edu> Hi Randy (or anyone on m3devel), Have you considered my bug report? Can someone who knows the code better than me analyze the situation and either clear my code or justify the existing code as checked in and tell me what I'm doing wrong? I have had to change the code as I described in my old pm3 sources to get my application working, tired of doing workarounds. I strongly suspect we're dealing with an annoying bug, and it looks present in both Pickle.m3 and Pickle2.m3, all versions (CM3, PM3 at least). Mika "Coleburn, Randy" writes: >Hi Mika: > >I'm deep in the middle of some other stuff, but read your post with interes= >t because I've done a LOT of work with both Pickles and Network Objects. > >On the surface, I'm not sure whether this is a bug or not. I've never enco= >untered this problem before. But, my brain is in left-field right now with= > all else I have going on. > >I know that I always used the Pickle2 (2nd generation of pickles) to get ar= >ound some problems with the first generation. I never used PM3, just CM3 a= >nd the original "SRC-Systems Research Center" versions. > >I know you can also write and register special "pickler" procedures for any= > particular object to get around problems with the default pickling procedu= >res (read/write). I've had to do this on occasion both to resolve problems= > and to increase performance. I can provide examples if you need them. > >--Randy > >Randy C. Coleburn, CISSP-ISSEP, GCED >Corporate Information Security Officer (CISO) >Scientific Research Corporation > >-----Original Message----- >From: mika at async.caltech.edu [mailto:mika at async.caltech.edu]=20 >Sent: Thursday, June 27, 2013 7:01 PM >To: m3devel at elegosoft.com >Subject: EXT:[M3devel] netobj bug report > >Hi m3devel, > >I think I found a bug in the Network Objects code. > >Here is what I was doing: I made an object that I wanted to export using Ne= >twork Objects, but I *also* wanted to Pickle the object locally (for persis= >tence). > >I find that if I create the object and try to pickle it, I get a Pickle err= >or "Can't pickle a surrogate object". =20 > >The source of the error is in StubLib.m3, the Pickle special that is record= >ed for network objects: > >PROCEDURE OutSpecial(self: Pickle.Special; > r: REFANY; > writer: Pickle.Writer) > RAISES {Pickle.Error, Wr.Failure, Thread.Alerted} =3D > BEGIN > TYPECASE writer OF > | SpecWr(wtr) =3D> OutRef(wtr.c, r); > ELSE > TYPECASE r OF > | NetObj.T(x) =3D> > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; > ELSE RAISE Pickle.Error("Can't Pickle Rd.T or Wr.T"); > END; > END; > END OutSpecial; > >(In CM3, OutSpecial2 has the same bug for Pickle2 pickles. PM3 doesn't hav= >e Pickle2 nor OutSpecial2.) > >The problem is the test > > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; > >The intent, I think, is that an object that is remote (that is, has x.r of = >type Transport.Location) should not be pickle-able. > >The problem is that x.r is initially NIL, and NIL is a member of Transport.= >Location. > >My workaround is to FIRST export the object before attempting to Pickle it.= > This works fine but it shouldn't be necessary, should it? What if I don'= >t want to export the object, but just pickle it? > >I believe the test should be changed to be > >IF x.r =3D NIL OR NOT ISTYPE(x.r, Transport.Location) THEN... > > Mika > From rodney_bates at lcwb.coop Tue Jul 2 00:40:41 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 01 Jul 2013 17:40:41 -0500 Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? Message-ID: <51D20569.1010600@lcwb.coop> After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll total 792 -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp where parse.c is changed. When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l total 1944 -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c ../../gcc-4.7/gcc/m3cg/parse.c But parse.o has not changed (I can verify this by running gdb on cm3cg), and: rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll total 792 -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp My edits to parse.c have been undone! If I recreate the edited parse.c, then chmod 444 parse.c and recompile, it has no effect. parse.c still gets changed back to the unedited version. Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory (I have no idea how long this has been the case), and I have not been able to get cvs to admit to having any awareness of this directory or anything in it, using cvs log, cvs update or cvs checkout. I even tried manually creating a CVS subdirectory, but without getting cvs to tell me something about its current version number of parse.c, I can't create a line in CVS/Entries for it, and cvs continues to claim total ignorance of this file. What is going on here? Is parse.c (and all of m3cg) being automatically created? From where? cvs update -P does not remove m3cg, BTW. From jay.krell at cornell.edu Tue Jul 2 03:48:00 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 2 Jul 2013 01:48:00 +0000 Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? In-Reply-To: <51D20569.1010600@lcwb.coop> References: <51D20569.1010600@lcwb.coop> Message-ID: There is one parse.c for several gcc forks. It is copied or linked by m3makefile. - Jay > Date: Mon, 1 Jul 2013 17:40:41 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? > > > After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > total 792 > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp > > where parse.c is changed. > > When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l > total 1944 > -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c > ../../gcc-4.7/gcc/m3cg/parse.c > > But parse.o has not changed (I can verify this by running gdb on cm3cg), and: > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > total 792 > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp > > My edits to parse.c have been undone! If I recreate the edited parse.c, > then chmod 444 parse.c and recompile, it has no effect. parse.c still > gets changed back to the unedited version. > > Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory > (I have no idea how long this has been the case), and I have not been able > to get cvs to admit to having any awareness of this directory or anything in it, > using cvs log, cvs update or cvs checkout. I even tried manually creating a > CVS subdirectory, but without getting cvs to tell me something about its current > version number of parse.c, I can't create a line in CVS/Entries for it, and cvs > continues to claim total ignorance of this file. > > What is going on here? Is parse.c (and all of m3cg) being automatically created? > From where? > > cvs update -P does not remove m3cg, BTW. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Jul 2 16:31:26 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 02 Jul 2013 09:31:26 -0500 Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? In-Reply-To: References: <51D20569.1010600@lcwb.coop> Message-ID: <51D2E43E.8020803@lcwb.coop> OK. Is it the one in m3-sys/m3cc/gcc/gcc/m3cg? This has a CVS directory, while gcc-4.5 and gcc-4.7 do not, and m3-sys/m3cc-old doesn't sound promising. Does it work the same way for all the files in m3cg? On 07/01/2013 08:48 PM, Jay K wrote: > There is one parse.c for several gcc forks. It is copied or linked by m3makefile. > > - Jay > > > Date: Mon, 1 Jul 2013 17:40:41 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? > > > > > > After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > > total 792 > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > > -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp > > > > where parse.c is changed. > > > > When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l > > total 1944 > > -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c > > ../../gcc-4.7/gcc/m3cg/parse.c > > > > But parse.o has not changed (I can verify this by running gdb on cm3cg), and: > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > > total 792 > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp > > > > My edits to parse.c have been undone! If I recreate the edited parse.c, > > then chmod 444 parse.c and recompile, it has no effect. parse.c still > > gets changed back to the unedited version. > > > > Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory > > (I have no idea how long this has been the case), and I have not been able > > to get cvs to admit to having any awareness of this directory or anything in it, > > using cvs log, cvs update or cvs checkout. I even tried manually creating a > > CVS subdirectory, but without getting cvs to tell me something about its current > > version number of parse.c, I can't create a line in CVS/Entries for it, and cvs > > continues to claim total ignorance of this file. > > > > What is going on here? Is parse.c (and all of m3cg) being automatically created? > > From where? > > > > cvs update -P does not remove m3cg, BTW. > > > > From jay.krell at cornell.edu Wed Jul 3 03:56:05 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Jul 2013 01:56:05 +0000 Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? In-Reply-To: <51D2E43E.8020803@lcwb.coop> References: <51D20569.1010600@lcwb.coop> , <51D2E43E.8020803@lcwb.coop> Message-ID: Yes, there is just one copy of the directory. Look in m3cc/src/m3makefile. Sometimes maybe a prefix is copied followed by the rest of the file, e.g. #define GCC47 ... contents of parse.c ... The #defines have a mix of meanings. GCC12 might mean exactly GCC 1.2, or it might mean 1.2 or newer. And there is GCC_APPLE, which goes along with gcc 4.2. I'm sorry about that. It could/should be cleaned up. If you really want, consider some things: 1) make entire copies of the file 2) split the file up and copy some of them, while keeping others identical Most of the code is indeed identical. So I don't like #1. In the case of #2, the bulk of the content would remain where it is, in the one parse.c, so history would be reasonable. Preserving history is of some concern, but CVS works poorly enough, and perhaps we renamed the directories in the past, so I'd be ok with having to jump around to trace history accurately. Or leave things mostly asis. And/or cleanup the meanings or "granularity" of the #defines. And/or drop support for all but the latest? I didn't get around to moving every target forward. Mainline gcc does not support OpenBSD for example, so I/we always have to do at least a tiny bit of work there. The OpenBSD ports/packages system does maintain patches for gcc. Many are outside the backend, and they are all trivial, stuff like picking size_t and pre-#definining __OpenBSD__ or such. Interix also requires moving small non-Modula-3 patches forward. iPhone/ARM_DARWIN would remain at 4.2 also, probably. I got as far there as starting up the compiler, which is pretty far. I have a number of times edited the wrong file only to have it overwritten by m3makefile. That is an unfortunate fallout of this scheme. But, as I said, most of the contents of the file are portable across several gcc versions. Hopefully I'll back to the C backend and moot this.. :( Anyway, if you look at the source and CVS, it should be /reasonably/ clear. I don't know/remember what m3cc-old is. There is some pain around "GTY". The syntax for it changed across gcc versions, like GTY struct foo vs. struct GTY foo or struct foo GTY. This is the annotation you put on types for the gcc garbage collector. So for that I did split a little bit of content into a different file. - Jay > Date: Tue, 2 Jul 2013 09:31:26 -0500 > From: rodney_bates at lcwb.coop > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? > > OK. Is it the one in m3-sys/m3cc/gcc/gcc/m3cg? This has a CVS directory, while > gcc-4.5 and gcc-4.7 do not, and m3-sys/m3cc-old doesn't sound promising. > > Does it work the same way for all the files in m3cg? > > On 07/01/2013 08:48 PM, Jay K wrote: > > There is one parse.c for several gcc forks. It is copied or linked by m3makefile. > > > > - Jay > > > > > Date: Mon, 1 Jul 2013 17:40:41 -0500 > > > From: rodney_bates at lcwb.coop > > > To: m3devel at elegosoft.com > > > Subject: [M3devel] What is going on with m3-sys/m3cc/gcc-4.7.gcc/m3cg? > > > > > > > > > After cvs update, in the head, if I edit m3-sys/m3cc/gcc-4.7/gcc/m3cg/parse.c, I see > > > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > > > total 792 > > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > > > -r--r--r-- 1 rodney rodney 183226 2013-07-01 17:13 parse.c > > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.temp > > > > > > where parse.c is changed. > > > > > > When I recompile, (using scripts/do-cm3-front.sh), I see parse.c being recompiled, and > > > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ ls -l > > > total 1944 > > > -rw-r--r-- 1 rodney rodney 1982736 2013-07-01 17:14 parse.o > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/AMD64_LINUX/gcc/m3cg$ strings parse.o | grep parse.c > > > ../../gcc-4.7/gcc/m3cg/parse.c > > > > > > But parse.o has not changed (I can verify this by running gdb on cm3cg), and: > > > > > > rodney at allegheny:~/proj/m3/cm3-new/cm3/m3-sys/m3cc/gcc-4.7/gcc/m3cg$ ll > > > total 792 > > > -rw-r--r-- 1 rodney rodney 1276 2011-05-19 10:58 config-lang.in > > > -rw-r--r-- 1 rodney rodney 1357 2006-09-01 18:16 lang.opt > > > -rw-r--r-- 1 rodney rodney 1524 2003-01-05 17:19 lang-options.h > > > -rw-r--r-- 1 rodney rodney 1002 2006-09-01 18:16 lang-specs.h > > > -rw-r--r-- 1 rodney rodney 12875 2013-02-08 09:49 m3cg.h > > > -rw-r--r-- 1 rodney rodney 11847 2010-11-15 04:09 m3-def.h > > > -rw-r--r-- 1 rodney rodney 2273 2011-05-19 10:58 m3gty43.h > > > -rw-r--r-- 1 rodney rodney 756 2013-02-08 09:49 m3-parse.h > > > -rw-r--r-- 1 rodney rodney 3497 2013-05-09 11:46 Make-lang.in > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c > > > -rw-r--r-- 1 rodney rodney 182831 2013-05-09 13:10 parse.c.~1~ > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:11 parse.c.~2~ > > > -rw-r--r-- 1 rodney rodney 182831 2013-07-01 17:14 parse.c.temp > > > > > > My edits to parse.c have been undone! If I recreate the edited parse.c, > > > then chmod 444 parse.c and recompile, it has no effect. parse.c still > > > gets changed back to the unedited version. > > > > > > Moreover, my directory m3-sys/m3cc/gcc-4.7/gcc/m3cg has no CVS subdirectory > > > (I have no idea how long this has been the case), and I have not been able > > > to get cvs to admit to having any awareness of this directory or anything in it, > > > using cvs log, cvs update or cvs checkout. I even tried manually creating a > > > CVS subdirectory, but without getting cvs to tell me something about its current > > > version number of parse.c, I can't create a line in CVS/Entries for it, and cvs > > > continues to claim total ignorance of this file. > > > > > > What is going on here? Is parse.c (and all of m3cg) being automatically created? > > > From where? > > > > > > cvs update -P does not remove m3cg, BTW. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Jul 7 04:11:18 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 6 Jul 2013 22:11:18 -0400 Subject: [M3devel] Multiple executables from the same source Message-ID: <20130707021118.GA9726@topoi.pooq.com> I'm writiing and debugging a bunch of interfaces and modules. They are all supposed to fit together into one happy executable. But of course, until I've finished debugging them they fit together into one unhappy executable. To test them properly I'd like to write a series of unit tests. To run these tests I will need to make further executables, each consisting of a test modules and several of the modules under test. Now with the usual structure of a Modula 3 workspace, there is one m3makefile and a src directory, and it makes one executable, not many, and it doesn't really give me a choice of which executable I want. In the old days of C code and Makefiles, I could have multiple targets each one being built with its own cc command with its own list of source files names. Is there anything comparable for Modula 3? The best I've come up sith so far is to have a number of directories, one for each test case, with its own m3makefile and its own symbolic link to a common src directory. Is there something better? I'm not really interested in having all the test code be part of the final application. For one thing, I'd like to be able to test multiple implementations of a single interface, such as a reference implementation and an efficient one, so that I can compare the output and complain about the differences. -- hendrik From jay.krell at cornell.edu Sun Jul 7 07:46:03 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Jul 2013 05:46:03 +0000 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <20130707021118.GA9726@topoi.pooq.com> References: <20130707021118.GA9726@topoi.pooq.com> Message-ID: I think you have multiple obvious choices, that you are aware of, that you don't think you want: 1) put it all in one src, one executable, a command line switch to choice the test case, AND have an option in the m3makefile and Main.m3 to omit the test code 1b) or just live it with it all being present all the time 2) break out the code into multiple libraries and multiple executables; including having more stuff in your public interface than you otherwise would.. "Hey, look", I've worked with a few build systems. Mostly NT Build. There seems to be some Digital (DEC) line of descent visible in about half of the programming world, and Modula-3 and NT and NT Build live there. (The other half is Unix). m3quake and NT Build have an amazing coincidence in overall design and feel. They both are declarative with an escape. NT Build is actually a thin wrapper over nmake, such that many people don't realize nmake is there, but the escape is nmake/makefile.inc. m3quake/cm3 is its own language, the declarations are actually function calls, and the escape is the fairly general scripting language. Most people just use the declarative stuff and don't break out into the programming language. (NT Build is publically available in the Windows DDK, at least until recent versions.) They both limit, mostly, source files to be in leaf directories. You can't reach around and build random source from random other places. Unless you turn it into a library or .obj. NT Build does have an obscure little used feature named UMTEST/UMAPPL. Where you can build multiple test apps in one leaf. They are afforded one source file each, and I think link to the rest of the directory, i.e. a library. In specifying these test cases though, the full generality of what you can do in a directory is lost. In m3quake/cm3-speak -- consider "import". Which executable are you importing for? One special one? All of them? The same problems.. Given the successful scale of both of these systems (really, of NT build), I suggest the designers knew very well what they were doing and anything we complain is missing, they were probably actually doing us a favor by omitting, we should live with the limitations and be happy to have received such a decent scalable design. :) > with its own m3makefile and its own symbolic link to a common src directory. And how are you going to check that into CVS and sync and build it on file systems without symlinks? Not portable. - Jay > Date: Sat, 6 Jul 2013 22:11:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: [M3devel] Multiple executables from the same source > > I'm writiing and debugging a bunch of interfaces and modules. > They are all supposed to fit together into one happy executable. > > But of course, until I've finished debugging them > they fit together into one unhappy executable. > To test them properly I'd like to write a series of unit tests. > To run these tests I will need to make further executables, > each consisting of a test modules and several of the modules under test. > > Now with the usual structure of a Modula 3 workspace, > there is one m3makefile and a src directory, and it makes one executable, > not many, > and it doesn't really give me a choice of which executable I want. > > In the old days of C code and Makefiles, I could have multiple targets > each one being built with its own cc command > with its own list of source files names. > > Is there anything comparable for Modula 3? > > The best I've come up sith so far is to have a number of directories, > one for each test case, > with its own m3makefile and its own symbolic link to a common src directory. > > Is there something better? > > I'm not really interested in having all the test code > be part of the final application. > > For one thing, > I'd like to be able to test multiple implementations of a single interface, > such as a reference implementation and an efficient one, > so that I can compare the output and complain about the differences. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 7 10:13:42 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Jul 2013 08:13:42 +0000 Subject: [M3devel] Multiple executables from the same source In-Reply-To: References: <20130707021118.GA9726@topoi.pooq.com>, Message-ID: > I'd like to be able to test multiple implementations of a single interface, I suggest you use objects here. And a common base type. Like how "interface" is interpreted in Java, C#, and COM. Modula-3 supports this well enough, just with different terminology. - Jay From: jay.krell at cornell.edu To: hendrik at topoi.pooq.com; m3devel at elegosoft.com Date: Sun, 7 Jul 2013 05:46:03 +0000 Subject: Re: [M3devel] Multiple executables from the same source I think you have multiple obvious choices, that you are aware of, that you don't think you want: 1) put it all in one src, one executable, a command line switch to choice the test case, AND have an option in the m3makefile and Main.m3 to omit the test code 1b) or just live it with it all being present all the time 2) break out the code into multiple libraries and multiple executables; including having more stuff in your public interface than you otherwise would.. "Hey, look", I've worked with a few build systems. Mostly NT Build. There seems to be some Digital (DEC) line of descent visible in about half of the programming world, and Modula-3 and NT and NT Build live there. (The other half is Unix). m3quake and NT Build have an amazing coincidence in overall design and feel. They both are declarative with an escape. NT Build is actually a thin wrapper over nmake, such that many people don't realize nmake is there, but the escape is nmake/makefile.inc. m3quake/cm3 is its own language, the declarations are actually function calls, and the escape is the fairly general scripting language. Most people just use the declarative stuff and don't break out into the programming language. (NT Build is publically available in the Windows DDK, at least until recent versions.) They both limit, mostly, source files to be in leaf directories. You can't reach around and build random source from random other places. Unless you turn it into a library or .obj. NT Build does have an obscure little used feature named UMTEST/UMAPPL. Where you can build multiple test apps in one leaf. They are afforded one source file each, and I think link to the rest of the directory, i.e. a library. In specifying these test cases though, the full generality of what you can do in a directory is lost. In m3quake/cm3-speak -- consider "import". Which executable are you importing for? One special one? All of them? The same problems.. Given the successful scale of both of these systems (really, of NT build), I suggest the designers knew very well what they were doing and anything we complain is missing, they were probably actually doing us a favor by omitting, we should live with the limitations and be happy to have received such a decent scalable design. :) > with its own m3makefile and its own symbolic link to a common src directory. And how are you going to check that into CVS and sync and build it on file systems without symlinks? Not portable. - Jay > Date: Sat, 6 Jul 2013 22:11:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: [M3devel] Multiple executables from the same source > > I'm writiing and debugging a bunch of interfaces and modules. > They are all supposed to fit together into one happy executable. > > But of course, until I've finished debugging them > they fit together into one unhappy executable. > To test them properly I'd like to write a series of unit tests. > To run these tests I will need to make further executables, > each consisting of a test modules and several of the modules under test. > > Now with the usual structure of a Modula 3 workspace, > there is one m3makefile and a src directory, and it makes one executable, > not many, > and it doesn't really give me a choice of which executable I want. > > In the old days of C code and Makefiles, I could have multiple targets > each one being built with its own cc command > with its own list of source files names. > > Is there anything comparable for Modula 3? > > The best I've come up sith so far is to have a number of directories, > one for each test case, > with its own m3makefile and its own symbolic link to a common src directory. > > Is there something better? > > I'm not really interested in having all the test code > be part of the final application. > > For one thing, > I'd like to be able to test multiple implementations of a single interface, > such as a reference implementation and an efficient one, > so that I can compare the output and complain about the differences. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Jul 7 15:08:12 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 7 Jul 2013 09:08:12 -0400 Subject: [M3devel] Multiple executables from the same source In-Reply-To: References: <20130707021118.GA9726@topoi.pooq.com> Message-ID: <20130707130811.GA9183@topoi.pooq.com> On Sun, Jul 07, 2013 at 05:46:03AM +0000, Jay K wrote: > > And how are you going to check that into CVS and sync and build it on file systems without symlinks? Instead of CVS I use monotone, which does handle symbolic links. Or I could have a makefile that makes the symbolic links as needed. > Not portable. Yes, that bothers me. It's one of the reasons the symbolic link seemed like a kludge to me. I'll look into your suggestions. -- hendrik From hendrik at topoi.pooq.com Sun Jul 7 17:58:18 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 7 Jul 2013 11:58:18 -0400 Subject: [M3devel] Multiple executables from the same source In-Reply-To: References: <20130707021118.GA9726@topoi.pooq.com> Message-ID: <20130707155818.GB10466@topoi.pooq.com> On Sun, Jul 07, 2013 at 05:46:03AM +0000, Jay K wrote: > m3quake/cm3 is its own language, the declarations are actually > function calls, and the escape is the fairly general scripting > language. Most people just use the declarative stuff and don't break > out into the programming language. So you mean I should use something like if (test) implementation("Test") program("Test") else implementation("Main") program("Main") end in the m3makefile and run it with something like cm3 -Dtest Seems to work. Thanks. Now that I know what to look for, finding http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html made it relatively straightforward. -- hendrik From hendrik at topoi.pooq.com Sun Jul 7 18:39:17 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 7 Jul 2013 12:39:17 -0400 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <20130707155818.GB10466@topoi.pooq.com> References: <20130707021118.GA9726@topoi.pooq.com> <20130707155818.GB10466@topoi.pooq.com> Message-ID: <20130707163917.GA10814@topoi.pooq.com> On Sun, Jul 07, 2013 at 11:58:18AM -0400, Hendrik Boom wrote: > On Sun, Jul 07, 2013 at 05:46:03AM +0000, Jay K wrote: > > m3quake/cm3 is its own language, the declarations are actually > > function calls, and the escape is the fairly general scripting > > language. Most people just use the declarative stuff and don't break > > out into the programming language. > > So you mean I should use something like > > > if (test) correction: if defined("test") > implementation("Test") > program("Test") > else > implementation("Main") > program("Main") > end > > in the m3makefile > > and run it with something like > > cm3 -Dtest > > Seems to work. Thanks. Now that I know what to look for, finding > http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html made it > relatively straightforward. > > -- hendrik From hendrik at topoi.pooq.com Mon Jul 8 15:45:10 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 8 Jul 2013 09:45:10 -0400 Subject: [M3devel] I don't know what changed, or when, but thanks! Message-ID: <20130708134510.GA20805@topoi.pooq.com> Years ago, when a Modula 3 program failed because I called an absent method, it was difficult findig where the error was. But yesterday, I just ran the program in m3gdb and got a backtrace after failure. Of course the backtrace was full of apparent gibberish, but right in the middle is said: at ../src/runtime/common/RTException.m3:25 #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol table. ) at ../src/runtime/ex_frame/RTExFrame.m3:29 #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. ) at ../src/runtime/common/RTType.m3:850 #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in symbol table. ) at ../src/runtime/common/RTType.m3:834 #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol table. ) at ../src/Parse.m3:115 ---Type to continue, or q to quit--- #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol table. ) at ../src/Parse.m3:354 #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol table. ) at ../src/Main.m3:202 So it was quite clear I had to look at ../src/Parse.m3:115, and it was obvious where I had left our a shift := shift line in an OVERRIDES list. -- hendrik From rodney_bates at lcwb.coop Mon Jul 8 17:36:29 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 08 Jul 2013 10:36:29 -0500 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <20130708134510.GA20805@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> Message-ID: <51DADC7D.5060606@lcwb.coop> If you get m3gdb to realize this is modula-3 code, there will be a lot more useful info in the backtrace, like parameter values. Probably just doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. If you are using the head compiler and debugger, you will need very recent ones (perhaps in the last month?), as changes in the code generator created some regressions. All that I have seen are now fixed in the current head. On 07/08/2013 08:45 AM, Hendrik Boom wrote: > Years ago, when a Modula 3 program failed because I called an absent > method, it was difficult findig where the error was. > > But yesterday, I just ran the program in m3gdb and got a backtrace > after failure. > > Of course the backtrace was full of apparent gibberish, but right in > the middle is said: > > at ../src/runtime/common/RTException.m3:25 > #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol > table. > ) at ../src/runtime/ex_frame/RTExFrame.m3:29 > #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. > ) at ../src/runtime/common/RTType.m3:850 > #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in > symbol table. > ) > at ../src/runtime/common/RTType.m3:834 > #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol > table. > ) at ../src/Parse.m3:115 > ---Type to continue, or q to quit--- > #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol > table. > ) at ../src/Parse.m3:354 > #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol > table. > ) at ../src/Main.m3:202 > > > So it was quite clear I had to look at ../src/Parse.m3:115, and it was > obvious where I had left our a shift := shift line in an OVERRIDES > list. > > -- hendrik > > From rodney_bates at lcwb.coop Mon Jul 8 17:51:41 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 08 Jul 2013 10:51:41 -0500 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <20130707021118.GA9726@topoi.pooq.com> References: <20130707021118.GA9726@topoi.pooq.com> Message-ID: <51DAE00D.3090508@lcwb.coop> On 07/06/2013 09:11 PM, Hendrik Boom wrote: > I'm writiing and debugging a bunch of interfaces and modules. > They are all supposed to fit together into one happy executable. > > But of course, until I've finished debugging them > they fit together into one unhappy executable. > To test them properly I'd like to write a series of unit tests. > To run these tests I will need to make further executables, > each consisting of a test modules and several of the modules under test. > > Now with the usual structure of a Modula 3 workspace, > there is one m3makefile and a src directory, and it makes one executable, > not many, > and it doesn't really give me a choice of which executable I want. > > In the old days of C code and Makefiles, I could have multiple targets > each one being built with its own cc command > with its own list of source files names. > > Is there anything comparable for Modula 3? > > The best I've come up sith so far is to have a number of directories, > one for each test case, > with its own m3makefile and its own symbolic link to a common src directory. I have one project with three executables and a majority of the code shared. I am using essentially this scheme, but instead of the symlinks in the directories, I have 'include_dir("../common/src")' in the m3makefiles of the main programs. common/src has its m3makefile for all the stuff in common. This means means every main program has to independently compile all the common stuff and keep its own copies thereof. But disk is cheap and plentiful, and 200K..300K SLOC compiles from scratch fast enough. Someday, when bored, I plan to make the common stuff a separate library package. But then I will have to remember to recompile it when it changes, before compiling a main package. I have often thought about a second level of automatic, inter-package recompilation. It would have saved me some grief on occasions. But it could introduce new problems too. > > Is there something better? > > I'm not really interested in having all the test code > be part of the final application. > > For one thing, > I'd like to be able to test multiple implementations of a single interface, > such as a reference implementation and an efficient one, > so that I can compare the output and complain about the differences. > > -- hendrik > From hendrik at topoi.pooq.com Mon Jul 8 18:25:40 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 8 Jul 2013 12:25:40 -0400 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <51DAE00D.3090508@lcwb.coop> References: <20130707021118.GA9726@topoi.pooq.com> <51DAE00D.3090508@lcwb.coop> Message-ID: <20130708162540.GA22041@topoi.pooq.com> On Mon, Jul 08, 2013 at 10:51:41AM -0500, Rodney M. Bates wrote: > > > On 07/06/2013 09:11 PM, Hendrik Boom wrote: > >I'm writiing and debugging a bunch of interfaces and modules. > >They are all supposed to fit together into one happy executable. > > > >But of course, until I've finished debugging them > > they fit together into one unhappy executable. > >To test them properly I'd like to write a series of unit tests. > >To run these tests I will need to make further executables, > > each consisting of a test modules and several of the modules under test. > > > >Now with the usual structure of a Modula 3 workspace, > > there is one m3makefile and a src directory, and it makes one executable, > > not many, > > and it doesn't really give me a choice of which executable I want. > > > >In the old days of C code and Makefiles, I could have multiple targets > > each one being built with its own cc command > > with its own list of source files names. > > > >Is there anything comparable for Modula 3? > > > >The best I've come up sith so far is to have a number of directories, > > one for each test case, > > with its own m3makefile and its own symbolic link to a common src directory. > > I have one project with three executables and a majority of the code shared. I > am using essentially this scheme, but instead of the symlinks in the directories, > I have 'include_dir("../common/src")' in the m3makefiles of the main programs. > common/src has its m3makefile for all the stuff in common. Is this a way of getting cm3 to search ../common/src as sell as the src it usually looks through? That may be what I wanted ... but IF statements in m3makefiles suffice for now. It's useful to know that include_dir is available, though. Is there any advice how to make sure the variable names I use in an m3makefiles don't confllict with the ones that cm3 might be using to manage the compilation? > > This means means every main program has to independently compile all the common > stuff and keep its own copies thereof. But disk is cheap and plentiful, > and 200K..300K SLOC compiles from scratch fast enough. Independently compiling all that stuff is what I originally wanted -- it would give me the option of trying independent and very different implementations for some interfaces so as to discover hidden logical dependencies. And the extra disk space is not that much space -- considering that it only needs to be tied up during testing, -- hendrik From hendrik at topoi.pooq.com Mon Jul 8 18:30:38 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 8 Jul 2013 12:30:38 -0400 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <51DADC7D.5060606@lcwb.coop> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> Message-ID: <20130708163038.GB22041@topoi.pooq.com> On Mon, Jul 08, 2013 at 10:36:29AM -0500, Rodney M. Bates wrote: > If you get m3gdb to realize this is modula-3 code, there will be a lot > more useful info in the backtrace, like parameter values. Probably just > doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. Yes, that would probably help. > > If you are using the head compiler and debugger, you will need very > recent ones (perhaps in the last month?), as changes in the code > generator created some regressions. All that I have seen are now > fixed in the current head. Time to upgrade, then. Please understand, I was being genuinely happy, not complaining in a sarcastic way. Knowing just where I called into deep space was a huge time-saver. -- hendrik > > On 07/08/2013 08:45 AM, Hendrik Boom wrote: > >Years ago, when a Modula 3 program failed because I called an absent > >method, it was difficult findig where the error was. > > > >But yesterday, I just ran the program in m3gdb and got a backtrace > >after failure. > > > >Of course the backtrace was full of apparent gibberish, but right in > >the middle is said: > > > > at ../src/runtime/common/RTException.m3:25 > >#14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol > >table. > >) at ../src/runtime/ex_frame/RTExFrame.m3:29 > >#15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. > >) at ../src/runtime/common/RTType.m3:850 > >#16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in > >symbol table. > >) > > at ../src/runtime/common/RTType.m3:834 > >#17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol > >table. > >) at ../src/Parse.m3:115 > >---Type to continue, or q to quit--- > >#18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol > >table. > >) at ../src/Parse.m3:354 > >#19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol > >table. > >) at ../src/Main.m3:202 > > > > > >So it was quite clear I had to look at ../src/Parse.m3:115, and it was > >obvious where I had left our a shift := shift line in an OVERRIDES > >list. > > > >-- hendrik > > > > > From rodney_bates at lcwb.coop Mon Jul 8 20:20:05 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 08 Jul 2013 13:20:05 -0500 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <20130708163038.GB22041@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> Message-ID: <51DB02D5.8070209@lcwb.coop> On 07/08/2013 11:30 AM, Hendrik Boom wrote: > On Mon, Jul 08, 2013 at 10:36:29AM -0500, Rodney M. Bates wrote: >> If you get m3gdb to realize this is modula-3 code, there will be a lot >> more useful info in the backtrace, like parameter values. Probably just >> doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. > > Yes, that would probably help. >> >> If you are using the head compiler and debugger, you will need very >> recent ones (perhaps in the last month?), as changes in the code >> generator created some regressions. All that I have seen are now >> fixed in the current head. > > Time to upgrade, then. > > Please understand, I was being genuinely happy, not complaining in a > sarcastic way. Yes, I read it that way, but I can sometimes get confused about that. BTW, you can also catch exception that is later handled, at the point where it is raised, by setting (in advance) a breakpoint in a place like Raise in the RTS. You could get lots of false hits this way though, if raise-handle of other exceptions is something that is happening routinely. > > Knowing just where I called into deep space was a huge time-saver. > > -- hendrik > >> >> On 07/08/2013 08:45 AM, Hendrik Boom wrote: >>> Years ago, when a Modula 3 program failed because I called an absent >>> method, it was difficult findig where the error was. >>> >>> But yesterday, I just ran the program in m3gdb and got a backtrace >>> after failure. >>> >>> Of course the backtrace was full of apparent gibberish, but right in >>> the middle is said: >>> >>> at ../src/runtime/common/RTException.m3:25 >>> #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol >>> table. >>> ) at ../src/runtime/ex_frame/RTExFrame.m3:29 >>> #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. >>> ) at ../src/runtime/common/RTType.m3:850 >>> #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in >>> symbol table. >>> ) >>> at ../src/runtime/common/RTType.m3:834 >>> #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol >>> table. >>> ) at ../src/Parse.m3:115 >>> ---Type to continue, or q to quit--- >>> #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol >>> table. >>> ) at ../src/Parse.m3:354 >>> #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol >>> table. >>> ) at ../src/Main.m3:202 >>> >>> >>> So it was quite clear I had to look at ../src/Parse.m3:115, and it was >>> obvious where I had left our a shift := shift line in an OVERRIDES >>> list. >>> >>> -- hendrik >>> >>> >> > From rodney_bates at lcwb.coop Mon Jul 8 20:13:16 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 08 Jul 2013 13:13:16 -0500 Subject: [M3devel] Multiple executables from the same source In-Reply-To: <20130708162540.GA22041@topoi.pooq.com> References: <20130707021118.GA9726@topoi.pooq.com> <51DAE00D.3090508@lcwb.coop> <20130708162540.GA22041@topoi.pooq.com> Message-ID: <51DB013C.6030200@lcwb.coop> On 07/08/2013 11:25 AM, Hendrik Boom wrote: > On Mon, Jul 08, 2013 at 10:51:41AM -0500, Rodney M. Bates wrote: >> >> >> On 07/06/2013 09:11 PM, Hendrik Boom wrote: >>> I'm writiing and debugging a bunch of interfaces and modules. >>> They are all supposed to fit together into one happy executable. >>> >>> But of course, until I've finished debugging them >>> they fit together into one unhappy executable. >>> To test them properly I'd like to write a series of unit tests. >>> To run these tests I will need to make further executables, >>> each consisting of a test modules and several of the modules under test. >>> >>> Now with the usual structure of a Modula 3 workspace, >>> there is one m3makefile and a src directory, and it makes one executable, >>> not many, >>> and it doesn't really give me a choice of which executable I want. >>> >>> In the old days of C code and Makefiles, I could have multiple targets >>> each one being built with its own cc command >>> with its own list of source files names. >>> >>> Is there anything comparable for Modula 3? >>> >>> The best I've come up sith so far is to have a number of directories, >>> one for each test case, >>> with its own m3makefile and its own symbolic link to a common src directory. >> >> I have one project with three executables and a majority of the code shared. I >> am using essentially this scheme, but instead of the symlinks in the directories, >> I have 'include_dir("../common/src")' in the m3makefiles of the main programs. >> common/src has its m3makefile for all the stuff in common. > > Is this a way of getting cm3 to search ../common/src as sell as the src > it usually looks through? Yes,, it uses ../common/src/m3makefile and whatever it refers to. I don't know the precise semantics, but I imagine it just interprets the contents of the included m3makefile in place of the include_dir. > > That may be what I wanted ... but IF statements in m3makefiles suffice > for now. > > It's useful to know that include_dir is available, though. > > Is there any advice how to make sure the variable names I use in an > m3makefiles don't confllict with the ones that cm3 might be using to > manage the compilation? > I don't think there is anything graceful here, other than try it and see if things blow up. >> >> This means means every main program has to independently compile all the common >> stuff and keep its own copies thereof. But disk is cheap and plentiful, >> and 200K..300K SLOC compiles from scratch fast enough. > > Independently compiling all that stuff is what I originally wanted -- > it would give me the option of trying independent and very different > implementations for some interfaces so as to discover hidden logical > dependencies. > > And the extra disk space is not that much space -- considering that > it only needs to be tied up during testing, > > -- hendrik > From hendrik at topoi.pooq.com Mon Jul 8 22:25:39 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 8 Jul 2013 16:25:39 -0400 Subject: [M3devel] typo in http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html Message-ID: <20130708202539.GA30241@topoi.pooq.com> The paragraph in section 9.8 that defines 'defined' has a typo: evaluated before begin passed to defined. instead of evaluated before being passed to defined. -- hendrik From mika at async.caltech.edu Thu Jul 11 11:08:04 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Thu, 11 Jul 2013 02:08:04 -0700 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <51DADC7D.5060606@lcwb.coop> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> Message-ID: <20130711090804.939171A207D@async.async.caltech.edu> This is just a pet peeve of mine, but I never remember to capitalize "Modula-3" right. There is no way to make m3gdb also recognize set lang m3 set lang modula3 set lang modula-3 set lang m0dulaIII etc...? "Rodney M. Bates" writes: >If you get m3gdb to realize this is modula-3 code, there will be a lot >more useful info in the backtrace, like parameter values. Probably just >doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. > >If you are using the head compiler and debugger, you will need very >recent ones (perhaps in the last month?), as changes in the code >generator created some regressions. All that I have seen are now >fixed in the current head. > >On 07/08/2013 08:45 AM, Hendrik Boom wrote: >> Years ago, when a Modula 3 program failed because I called an absent >> method, it was difficult findig where the error was. >> >> But yesterday, I just ran the program in m3gdb and got a backtrace >> after failure. >> >> Of course the backtrace was full of apparent gibberish, but right in >> the middle is said: >> >> at ../src/runtime/common/RTException.m3:25 >> #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol >> table. >> ) at ../src/runtime/ex_frame/RTExFrame.m3:29 >> #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. >> ) at ../src/runtime/common/RTType.m3:850 >> #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in >> symbol table. >> ) >> at ../src/runtime/common/RTType.m3:834 >> #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol >> table. >> ) at ../src/Parse.m3:115 >> ---Type to continue, or q to quit--- >> #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol >> table. >> ) at ../src/Parse.m3:354 >> #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol >> table. >> ) at ../src/Main.m3:202 >> >> >> So it was quite clear I had to look at ../src/Parse.m3:115, and it was >> obvious where I had left our a shift := shift line in an OVERRIDES >> list. >> >> -- hendrik >> >> From wagner at elego.de Thu Jul 11 11:20:18 2013 From: wagner at elego.de (Olaf Wagner) Date: Thu, 11 Jul 2013 11:20:18 +0200 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <20130711090804.939171A207D@async.async.caltech.edu> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130711090804.939171A207D@async.async.caltech.edu> Message-ID: <20130711112018.3bf3ba6f.wagner@elego.de> On Thu, 11 Jul 2013 02:08:04 -0700 mika at async.caltech.edu wrote: > This is just a pet peeve of mine, but I never remember to capitalize "Modula-3" right. > There is no way to make m3gdb also recognize > > set lang m3 +1 > set lang modula3 > set lang modula-3 > set lang m0dulaIII -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 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 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Thu Jul 11 17:56:35 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Thu, 11 Jul 2013 08:56:35 -0700 Subject: [M3devel] netobj bug report In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF2F168037@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF2F168037@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <20130711155635.869211A207D@async.async.caltech.edu> The code in CM3 is the same. I am 95% certain this is a bug. The logic just doesn't make sense. All you should have to do to reproduce it is the following: instantiate a subtype of NetObj.T without exporting it. Then try to Pickle it. Your program I think will crash (for no good reason). Your program I think will not crash if you do export it. The logic is checking for a surrogate and crashing if you attempt to pickle one: > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; The problem is that x.r is only non-NIL once you export the object. For a new object that has not been exported, x.r is NIL. Therefore it is of type Transport.Location and appears to be a surrogate, even though it is not a surrogate. The test should be IF x.r = NIL OR NOT ISTYPE... Mika "Coleburn, Randy" writes: >Hi Mika: > >I'm deep in the middle of some other stuff, but read your post with interes= >t because I've done a LOT of work with both Pickles and Network Objects. > >On the surface, I'm not sure whether this is a bug or not. I've never enco= >untered this problem before. But, my brain is in left-field right now with= > all else I have going on. > >I know that I always used the Pickle2 (2nd generation of pickles) to get ar= >ound some problems with the first generation. I never used PM3, just CM3 a= >nd the original "SRC-Systems Research Center" versions. > >I know you can also write and register special "pickler" procedures for any= > particular object to get around problems with the default pickling procedu= >res (read/write). I've had to do this on occasion both to resolve problems= > and to increase performance. I can provide examples if you need them. > >--Randy > >Randy C. Coleburn, CISSP-ISSEP, GCED >Corporate Information Security Officer (CISO) >Scientific Research Corporation > >-----Original Message----- >From: mika at async.caltech.edu [mailto:mika at async.caltech.edu]=20 >Sent: Thursday, June 27, 2013 7:01 PM >To: m3devel at elegosoft.com >Subject: EXT:[M3devel] netobj bug report > >Hi m3devel, > >I think I found a bug in the Network Objects code. > >Here is what I was doing: I made an object that I wanted to export using Ne= >twork Objects, but I *also* wanted to Pickle the object locally (for persis= >tence). > >I find that if I create the object and try to pickle it, I get a Pickle err= >or "Can't pickle a surrogate object". =20 > >The source of the error is in StubLib.m3, the Pickle special that is record= >ed for network objects: > >PROCEDURE OutSpecial(self: Pickle.Special; > r: REFANY; > writer: Pickle.Writer) > RAISES {Pickle.Error, Wr.Failure, Thread.Alerted} =3D > BEGIN > TYPECASE writer OF > | SpecWr(wtr) =3D> OutRef(wtr.c, r); > ELSE > TYPECASE r OF > | NetObj.T(x) =3D> > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; > ELSE RAISE Pickle.Error("Can't Pickle Rd.T or Wr.T"); > END; > END; > END OutSpecial; > >(In CM3, OutSpecial2 has the same bug for Pickle2 pickles. PM3 doesn't hav= >e Pickle2 nor OutSpecial2.) > >The problem is the test > > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; > >The intent, I think, is that an object that is remote (that is, has x.r of = >type Transport.Location) should not be pickle-able. > >The problem is that x.r is initially NIL, and NIL is a member of Transport.= >Location. > >My workaround is to FIRST export the object before attempting to Pickle it.= > This works fine but it shouldn't be necessary, should it? What if I don'= >t want to export the object, but just pickle it? > >I believe the test should be changed to be > >IF x.r =3D NIL OR NOT ISTYPE(x.r, Transport.Location) THEN... > > Mika > From rodney_bates at lcwb.coop Thu Jul 11 22:07:23 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 11 Jul 2013 15:07:23 -0500 Subject: [M3devel] I don't know what changed, or when, but thanks! In-Reply-To: <20130711090804.939171A207D@async.async.caltech.edu> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130711090804.939171A207D@async.async.caltech.edu> Message-ID: <51DF107B.9020600@lcwb.coop> On 07/11/2013 04:08 AM, mika at async.caltech.edu wrote: > This is just a pet peeve of mine, but I never remember to capitalize "Modula-3" right. > There is no way to make m3gdb also recognize > > set lang m3 > set lang modula3 > set lang modula-3 > set lang m0dulaIII Hmm,, I thought I had implemented recognition of several variants. From: modula3.elegosoft.com/cm3/doc/help/m3gdb/m3gdb-onepage.html#id372899 "In case you have trouble remembering which spelling of the language name to use, it accepts the cartesian product of "Modula" spelled out or abbreviated with a single "M", lowercase/uppercase "M", and with/without the hyphen." But this is for the "info Modula-3 command, not "set lang Modula-3". I'll add that to my list. I may not do the arbitrary mixed case, nor the Roman numeral, though, just yet :-). > > etc...? > > "Rodney M. Bates" writes: >> If you get m3gdb to realize this is modula-3 code, there will be a lot >> more useful info in the backtrace, like parameter values. Probably just >> doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. >> >> If you are using the head compiler and debugger, you will need very >> recent ones (perhaps in the last month?), as changes in the code >> generator created some regressions. All that I have seen are now >> fixed in the current head. >> >> On 07/08/2013 08:45 AM, Hendrik Boom wrote: >>> Years ago, when a Modula 3 program failed because I called an absent >>> method, it was difficult findig where the error was. >>> >>> But yesterday, I just ran the program in m3gdb and got a backtrace >>> after failure. >>> >>> Of course the backtrace was full of apparent gibberish, but right in >>> the middle is said: >>> >>> at ../src/runtime/common/RTException.m3:25 >>> #14 0xb6e3631c in Raise (act=Invalid C/C++ type code 30 in symbol >>> table. >>> ) at ../src/runtime/ex_frame/RTExFrame.m3:29 >>> #15 0xb6e30d1d in Fail (rte=Invalid C/C++ type code 23 in symbol table. >>> ) at ../src/runtime/common/RTType.m3:850 >>> #16 0xb6e30c4e in UndefinedMethod (self=Invalid C/C++ type code 46 in >>> symbol table. >>> ) >>> at ../src/runtime/common/RTType.m3:834 >>> #17 0x08063d45 in shift (new=Invalid C/C++ type code 26 in symbol >>> table. >>> ) at ../src/Parse.m3:115 >>> ---Type to continue, or q to quit--- >>> #18 0x08062fc4 in parse (input=Invalid C/C++ type code 26 in symbol >>> table. >>> ) at ../src/Parse.m3:354 >>> #19 0x08065be3 in Main (mode=Invalid C/C++ type code 39 in symbol >>> table. >>> ) at ../src/Main.m3:202 >>> >>> >>> So it was quite clear I had to look at ../src/Parse.m3:115, and it was >>> obvious where I had left our a shift := shift line in an OVERRIDES >>> list. >>> >>> -- hendrik >>> >>> > From hendrik at topoi.pooq.com Mon Jul 15 18:59:53 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 15 Jul 2013 12:59:53 -0400 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130708163038.GB22041@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> Message-ID: <20130715165952.GA6645@topoi.pooq.com> On Mon, Jul 08, 2013 at 12:30:38PM -0400, Hendrik Boom wrote: > On Mon, Jul 08, 2013 at 10:36:29AM -0500, Rodney M. Bates wrote: > > If you get m3gdb to realize this is modula-3 code, there will be a lot > > more useful info in the backtrace, like parameter values. Probably just > > doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. > > Yes, that would probably help. > > > > If you are using the head compiler and debugger, you will need very > > recent ones (perhaps in the last month?), as changes in the code > > generator created some regressions. All that I have seen are now > > fixed in the current head. > > Time to upgrade, then. I'm currently running version 5.8.6, which identifies itself as last updated on 2010-04-11. Is that still the latest release? I haven't found a newer. Does it come ddown to checking out current source from cvs and using my existing Modula 3 to compile it? And does cvsup work again? -- hendrik From rodney_bates at lcwb.coop Mon Jul 15 19:43:17 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 15 Jul 2013 12:43:17 -0500 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130715165952.GA6645@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> Message-ID: <51E434B5.3000706@lcwb.coop> On 07/15/2013 11:59 AM, Hendrik Boom wrote: > On Mon, Jul 08, 2013 at 12:30:38PM -0400, Hendrik Boom wrote: >> On Mon, Jul 08, 2013 at 10:36:29AM -0500, Rodney M. Bates wrote: >>> If you get m3gdb to realize this is modula-3 code, there will be a lot >>> more useful info in the backtrace, like parameter values. Probably just >>> doing a 'frame 17', or any M3 frame will do it, or 'set lang Modula-3'. >> >> Yes, that would probably help. >>> >>> If you are using the head compiler and debugger, you will need very >>> recent ones (perhaps in the last month?), as changes in the code >>> generator created some regressions. All that I have seen are now >>> fixed in the current head. >> >> Time to upgrade, then. > > I'm currently running version 5.8.6, which identifies itself as last > updated on 2010-04-11. Is that still the latest release? I haven't > found a newer. I think that is the latest release, or maybe the slightly updated cvs release branch. > > Does it come ddown to checking out current source from cvs and using > my existing Modula 3 to compile it? > If you are using or want to use the head version, yes. If you are using the release compiler and debugger, I think most or all of the regressions I referred to have happened since the release, so using that compiler may give you pretty much all m3gdb function as exists. I don't remember adding much new function in a while. It is possible however, to get the latest m3gdb from cvs head and compile and use it along with any of various older compilers and libraries, even PM3, EZM3, or, (gasp,) SRC M3. I always try to make m3gdb remain compatible with all the older compilers, whenever I add anything. > And does cvsup work again? I don't know about this. > > -- hendrik > From hendrik at topoi.pooq.com Thu Jul 18 19:14:56 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 18 Jul 2013 13:14:56 -0400 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <51E434B5.3000706@lcwb.coop> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> <51E434B5.3000706@lcwb.coop> Message-ID: <20130718171455.GA2631@topoi.pooq.com> On Mon, Jul 15, 2013 at 12:43:17PM -0500, Rodney M. Bates wrote: > > If you are using the release compiler and debugger, I think most or > all of the regressions I referred to have happened since the release, > so using that compiler may give you pretty much all m3gdb function > as exists. I don't remember adding much new function in a while. Just to be clear, by "the regressions since the release" do you mean problems that have appeaared since the release, or problems that have been fixed since the releases. > > It is possible however, to get the latest m3gdb from cvs head and compile > and use it along with any of various older compilers and libraries, > even PM3, EZM3, or, (gasp,) SRC M3. I always try to make m3gdb remain > compatible with all the older compilers, whenever I add anything. I have to say, still maintaining compatibility with SRC M3 is amazing. -- hendrik From dragisha at m3w.org Sun Jul 21 15:33:12 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Jul 2013 15:33:12 +0200 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130718171455.GA2631@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> <51E434B5.3000706@lcwb.coop> <20130718171455.GA2631@topoi.pooq.com> Message-ID: It's problems that have appeared, by definition of regression. -- Dragi?a Duri? dragisha at m3w.org On Jul 18, 2013, at 7:14 PM, Hendrik Boom wrote: > Just to be clear, by "the regressions since the release" do you mean > problems that have appeaared since the release, or problems that have > been fixed since the > releases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Jul 21 17:46:44 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Jul 2013 10:46:44 -0500 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130718171455.GA2631@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> <51E434B5.3000706@lcwb.coop> <20130718171455.GA2631@topoi.pooq.com> Message-ID: <51EC0264.600@lcwb.coop> On 07/18/2013 12:14 PM, Hendrik Boom wrote: > On Mon, Jul 15, 2013 at 12:43:17PM -0500, Rodney M. Bates wrote: >> >> If you are using the release compiler and debugger, I think most or >> all of the regressions I referred to have happened since the release, >> so using that compiler may give you pretty much all m3gdb function >> as exists. I don't remember adding much new function in a while. > > Just to be clear, by "the regressions since the release" do you mean > problems that have appeaared since the release, or problems that have > been fixed since the > releases. > Yes, I meant regressions that first appeared since the release. Not that there aren't heaps of bugs in m3gdb and its gcc-backend support, in the release and the head. I have probably a couple of dozen handwritten sheets with to-do notes for m3gdb. But there is a lot that does work. >> >> It is possible however, to get the latest m3gdb from cvs head and compile >> and use it along with any of various older compilers and libraries, >> even PM3, EZM3, or, (gasp,) SRC M3. I always try to make m3gdb remain >> compatible with all the older compilers, whenever I add anything. > > I have to say, still maintaining compatibility with SRC M3 is amazing. > > -- hendrik > From rodney_bates at lcwb.coop Sun Jul 21 17:52:22 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Jul 2013 10:52:22 -0500 Subject: [M3devel] Current version? (WAS: I don't know what changed, or when, but thanks!) In-Reply-To: <20130718171455.GA2631@topoi.pooq.com> References: <20130708134510.GA20805@topoi.pooq.com> <51DADC7D.5060606@lcwb.coop> <20130708163038.GB22041@topoi.pooq.com> <20130715165952.GA6645@topoi.pooq.com> <51E434B5.3000706@lcwb.coop> <20130718171455.GA2631@topoi.pooq.com> Message-ID: <51EC03B6.80103@lcwb.coop> On 07/18/2013 12:14 PM, Hendrik Boom wrote: > On Mon, Jul 15, 2013 at 12:43:17PM -0500, Rodney M. Bates wrote: >> >> If you are using the release compiler and debugger, I think most or >> all of the regressions I referred to have happened since the release, >> so using that compiler may give you pretty much all m3gdb function >> as exists. I don't remember adding much new function in a while. > > Just to be clear, by "the regressions since the release" do you mean > problems that have appeaared since the release, or problems that have > been fixed since the > releases. > >> >> It is possible however, to get the latest m3gdb from cvs head and compile >> and use it along with any of various older compilers and libraries, >> even PM3, EZM3, or, (gasp,) SRC M3. I always try to make m3gdb remain >> compatible with all the older compilers, whenever I add anything. > > I have to say, still maintaining compatibility with SRC M3 is amazing. Well, thank you. Actually, it's mostly just work and intention. Whenever some compiler change alters the runtime organization or the debug info, I don't strip out or modify what's there, I just add new alternative code and some detection of which to use. In a few places, it is difficult or impossible to distinguish something. A totally reworked debug info system, probably dwarf, would be refreshing, but it's a big job and there are priorities. > > -- hendrik > From rodney_bates at lcwb.coop Wed Jul 24 16:10:31 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Jul 2013 09:10:31 -0500 Subject: [M3devel] Pickles, TextLiterals, and word size Message-ID: <51EFE057.4030301@lcwb.coop> There is what I would call a bug in TextLiteral.i3 whose effect is that a TextLiteral.T has a different fingerprint on 32- and 64-bit machines. So you can't pickle a Text literal on one word-sized machine and unpickle it on the other. But fixing this will have the effect of invalidating any existing pickles written on a 64-bit machine before the fix, so they can't be read after the fix, even on a 64-bit machine. They would have to be rewritten after the fix. Is anybody doing the latter? Would having to recreate your pickles be a problem? Apparently, nobody is going cross-word-size, or we'd have heard about it. I would like to fix it properly, but don't want to undermine anybody's working system. From hendrik at topoi.pooq.com Wed Jul 24 17:34:47 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 24 Jul 2013 11:34:47 -0400 Subject: [M3devel] Pickles, TextLiterals, and word size In-Reply-To: <51EFE057.4030301@lcwb.coop> References: <51EFE057.4030301@lcwb.coop> Message-ID: <20130724153447.GA12587@topoi.pooq.com> On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote: > There is what I would call a bug in TextLiteral.i3 whose effect is that a > TextLiteral.T has a different fingerprint on 32- and 64-bit machines. > So you can't pickle a Text literal on one word-sized machine and unpickle > it on the other. > > But fixing this will have the effect of invalidating any existing pickles > written on a 64-bit machine before the fix, so they can't be read after > the fix, even on a 64-bit machine. They would have to be rewritten after > the fix. Ah! The problems of long-term compatibility! Is there any way of looking at a a pickle and determining whether it comes from a 32- of 64- bit machine? It there a way of special-casing the specific fingerprint that's about to be invalidated, so as to convert it properly on input only, while generating the new one on output? > > Is anybody doing the latter? Would having to recreate your pickles be a > problem? Apparently, nobody is going cross-word-size, or we'd have heard > about it. > > I would like to fix it properly, but don't want to undermine anybody's > working system. > From rcolebur at SCIRES.COM Wed Jul 24 19:03:12 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 24 Jul 2013 17:03:12 +0000 Subject: [M3devel] Pickles, TextLiterals, and word size In-Reply-To: <20130724153447.GA12587@topoi.pooq.com> References: <51EFE057.4030301@lcwb.coop>, <20130724153447.GA12587@topoi.pooq.com> Message-ID: <2CE8061F-4DF0-4645-AADB-F1582EDEDD73@SCIRES.COM> Hendrik raises some good questions. It would be great if "the fix" could be implemented in a way that either self-corrects for any pickles written prior to "the fix", or at least presents a run-time notification of a problem, but if this can't be done, I vote to go ahead with "the fix" and we will deal with it on a case-by-case basis. I've written a fair amount of stuff that uses pickles to persist object data on secondary storage, so I will have to deal with that, but I think it is more important this problem gets solved. Thanks, Randy Coleburn Sent from my iPad On Jul 24, 2013, at 11:34 AM, "Hendrik Boom" wrote: > On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote: >> There is what I would call a bug in TextLiteral.i3 whose effect is that a >> TextLiteral.T has a different fingerprint on 32- and 64-bit machines. >> So you can't pickle a Text literal on one word-sized machine and unpickle >> it on the other. >> >> But fixing this will have the effect of invalidating any existing pickles >> written on a 64-bit machine before the fix, so they can't be read after >> the fix, even on a 64-bit machine. They would have to be rewritten after >> the fix. > > Ah! The problems of long-term compatibility! > > Is there any way of looking at a a pickle and determining whether it > comes from a 32- of 64- bit machine? > > It there a way of special-casing the specific fingerprint that's about > to be invalidated, so as to convert it properly on input only, while > generating the new one on output? > >> >> Is anybody doing the latter? Would having to recreate your pickles be a >> problem? Apparently, nobody is going cross-word-size, or we'd have heard >> about it. >> >> I would like to fix it properly, but don't want to undermine anybody's >> working system. >> From rodney_bates at lcwb.coop Wed Jul 24 19:14:39 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Jul 2013 12:14:39 -0500 Subject: [M3devel] Pickles, TextLiterals, and word size In-Reply-To: <20130724153447.GA12587@topoi.pooq.com> References: <51EFE057.4030301@lcwb.coop> <20130724153447.GA12587@topoi.pooq.com> Message-ID: <51F00B7F.9020705@lcwb.coop> On 07/24/2013 10:34 AM, Hendrik Boom wrote: > On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote: >> There is what I would call a bug in TextLiteral.i3 whose effect is that a >> TextLiteral.T has a different fingerprint on 32- and 64-bit machines. >> So you can't pickle a Text literal on one word-sized machine and unpickle >> it on the other. >> >> But fixing this will have the effect of invalidating any existing pickles >> written on a 64-bit machine before the fix, so they can't be read after >> the fix, even on a 64-bit machine. They would have to be rewritten after >> the fix. > > Ah! The problems of long-term compatibility! > > Is there any way of looking at a a pickle and determining whether it > comes from a 32- of 64- bit machine? Yes, the pickle contains word size, LONGINT/LONGCARD size, floating point representation, endianness, lazy alignment, maximum alignment, record alignment, and now, widechar size, all for the system it was written on. > > It there a way of special-casing the specific fingerprint that's about > to be invalidated, so as to convert it properly on input only, while > generating the new one on output? > Yes, I thought about this. It would not be hard to find out what the two fingerprints are and test one read from a pickle against these values. But the problem is, there is an unbounded set of types that would depend indirectly on this, and they can't all be accounted for. Using, e.g., BITSIZE(INTEGER) as a bound in a range is the way this is happening it the subject case. Hmm, maybe I could just do the specific derived fingerprints for a TextLiteral.T, and that would be good enough. Let the programmer be responsible for other types. I think it would fix the immediate problem without undermining anything existing. I already have file dumps I can dig the values out of. I'll look into that. Thanks! >> >> Is anybody doing the latter? Would having to recreate your pickles be a >> problem? Apparently, nobody is going cross-word-size, or we'd have heard >> about it. >> >> I would like to fix it properly, but don't want to undermine anybody's >> working system. >> > From rodney_bates at lcwb.coop Wed Jul 24 22:59:12 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Jul 2013 15:59:12 -0500 Subject: [M3devel] Pickles, TextLiterals, and word size In-Reply-To: <51F00B7F.9020705@lcwb.coop> References: <51EFE057.4030301@lcwb.coop> <20130724153447.GA12587@topoi.pooq.com> <51F00B7F.9020705@lcwb.coop> Message-ID: <51F04020.1070200@lcwb.coop> On 07/24/2013 12:14 PM, Rodney M. Bates wrote: > > > On 07/24/2013 10:34 AM, Hendrik Boom wrote: >> On Wed, Jul 24, 2013 at 09:10:31AM -0500, Rodney M. Bates wrote: >>> There is what I would call a bug in TextLiteral.i3 whose effect is that a >>> TextLiteral.T has a different fingerprint on 32- and 64-bit machines. >>> So you can't pickle a Text literal on one word-sized machine and unpickle >>> it on the other. >>> >>> But fixing this will have the effect of invalidating any existing pickles >>> written on a 64-bit machine before the fix, so they can't be read after >>> the fix, even on a 64-bit machine. They would have to be rewritten after >>> the fix. >> >> Ah! The problems of long-term compatibility! >> >> Is there any way of looking at a a pickle and determining whether it >> comes from a 32- of 64- bit machine? > > Yes, the pickle contains word size, LONGINT/LONGCARD size, floating > point representation, endianness, lazy alignment, maximum alignment, > record alignment, and now, widechar size, all for the system it was > written on. > > >> >> It there a way of special-casing the specific fingerprint that's about >> to be invalidated, so as to convert it properly on input only, while >> generating the new one on output? >> > > Yes, I thought about this. It would not be hard to find out what the > two fingerprints are and test one read from a pickle against these values. > > But the problem is, there is an unbounded set of types that would depend > indirectly on this, and they can't all be accounted for. Using, e.g., > BITSIZE(INTEGER) as a bound in a range is the way this is happening > it the subject case. > > Hmm, maybe I could just do the specific derived fingerprints for a > TextLiteral.T, and that would be good enough. Let the programmer be > responsible for other types. I think it would fix the immediate > problem without undermining anything existing. No, that won't work either. That would only fix the case where the TextLiteral is the top-level, and thus only, "object" in a pickle. Not very likely. When the TextLiteral is a field/element of some containing object, it is the topmost object in the entire pickle whose fingerprint is used to find the type in the reading program. Actually, pickling a TextLiteral might not be very common at all. > > I already have file dumps I can dig the values out of. I'll look > into that. Thanks! > > >>> >>> Is anybody doing the latter? Would having to recreate your pickles be a >>> problem? Apparently, nobody is going cross-word-size, or we'd have heard >>> about it. >>> >>> I would like to fix it properly, but don't want to undermine anybody's >>> working system. >>> >> > > From mika at async.caltech.edu Sat Jul 27 05:07:17 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 26 Jul 2013 20:07:17 -0700 Subject: [M3devel] netobj bug report In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF2F168037@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF2F168037@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <20130727030717.095FD1A208C@async.async.caltech.edu> Hi Randy (or anyone on m3devel), Have you considered my bug report? Can someone who knows the code better than me analyze the situation and either clear my code or justify the existing code as checked in and tell me what I'm doing wrong? I have had to change the code as I described in my old pm3 sources to get my application working, tired of doing workarounds. I strongly suspect we're dealing with an annoying bug, and it looks present in both Pickle.m3 and Pickle2.m3, all versions (CM3, PM3 at least). Mika "Coleburn, Randy" writes: >Hi Mika: > >I'm deep in the middle of some other stuff, but read your post with interes= >t because I've done a LOT of work with both Pickles and Network Objects. > >On the surface, I'm not sure whether this is a bug or not. I've never enco= >untered this problem before. But, my brain is in left-field right now with= > all else I have going on. > >I know that I always used the Pickle2 (2nd generation of pickles) to get ar= >ound some problems with the first generation. I never used PM3, just CM3 a= >nd the original "SRC-Systems Research Center" versions. > >I know you can also write and register special "pickler" procedures for any= > particular object to get around problems with the default pickling procedu= >res (read/write). I've had to do this on occasion both to resolve problems= > and to increase performance. I can provide examples if you need them. > >--Randy > >Randy C. Coleburn, CISSP-ISSEP, GCED >Corporate Information Security Officer (CISO) >Scientific Research Corporation > >-----Original Message----- >From: mika at async.caltech.edu [mailto:mika at async.caltech.edu]=20 >Sent: Thursday, June 27, 2013 7:01 PM >To: m3devel at elegosoft.com >Subject: EXT:[M3devel] netobj bug report > >Hi m3devel, > >I think I found a bug in the Network Objects code. > >Here is what I was doing: I made an object that I wanted to export using Ne= >twork Objects, but I *also* wanted to Pickle the object locally (for persis= >tence). > >I find that if I create the object and try to pickle it, I get a Pickle err= >or "Can't pickle a surrogate object". =20 > >The source of the error is in StubLib.m3, the Pickle special that is record= >ed for network objects: > >PROCEDURE OutSpecial(self: Pickle.Special; > r: REFANY; > writer: Pickle.Writer) > RAISES {Pickle.Error, Wr.Failure, Thread.Alerted} =3D > BEGIN > TYPECASE writer OF > | SpecWr(wtr) =3D> OutRef(wtr.c, r); > ELSE > TYPECASE r OF > | NetObj.T(x) =3D> > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; > ELSE RAISE Pickle.Error("Can't Pickle Rd.T or Wr.T"); > END; > END; > END OutSpecial; > >(In CM3, OutSpecial2 has the same bug for Pickle2 pickles. PM3 doesn't hav= >e Pickle2 nor OutSpecial2.) > >The problem is the test > > IF NOT ISTYPE(x.r, Transport.Location) THEN > (* This will gratuitously pickle the ExportInfo ref > embedded in x.r. It would be better to exclude this > if and when possible, but it shouldn't hurt for now. *) > Pickle.Special.write(self, r, writer); > ELSE > RAISE Pickle.Error("Can't pickle a surrogate object"); > END; > >The intent, I think, is that an object that is remote (that is, has x.r of = >type Transport.Location) should not be pickle-able. > >The problem is that x.r is initially NIL, and NIL is a member of Transport.= >Location. > >My workaround is to FIRST export the object before attempting to Pickle it.= > This works fine but it shouldn't be necessary, should it? What if I don'= >t want to export the object, but just pickle it? > >I believe the test should be changed to be > >IF x.r =3D NIL OR NOT ISTYPE(x.r, Transport.Location) THEN... > > Mika >